⑴ 如何提高oracle 插入效率
Oracle 数据导入方法比较 每个数据库管理员都会面临数据导入的问题，这有可能发生在数据库的新老移植过程中，或者是在数据库崩溃后的恢复重建过程中，还有可能是在创建测试数据库的模拟环境过程中，总之作为一名合格的数据库管理员，你应该做好接受各种数据导入请求的技术储备，同时还要尽量满足人本能的对导入速度的苛求。本文仅针对 Oracle 数据库所提供的加速数据导入的各种特性和技术进行探讨，其中的一些方法也可以转化应用于其他数据库。以下七种数据导入方法哪个最适用需要针对具体情况具体分析，我也附带列举了影响导入速度的各种因素供斟酌。为了比较各种数据导入方法的效果，我创建了示例表和数据集，并用各种方法导入示例数据集来计算总体导入时间和导入进程占用 CPU 时间，这里得出的时间仅供参考。需要说明的是，建议你使用 Oracle 9i 企业版数据库，当然你也可以尝试使用 Oracle 7.3 以上的标准版数据库。本文使用的机器配置为：CPU Intel P4，内存 256M，数据库 Oracle 9i 企业版
示例表结构和数据集
为了演示和比较各种数据导入方法，我假定数据导入任务是将外部文件数据导入到 Oracle 数据库的CALLS表中，外部数据文件包含十万条呼叫中心记录，将近 6MB 的文件大小，具体的数据示例如下:
82302284384,2003-04-18:13:18:58,5001,投诉,手机三包维修质量82302284385,2003-04-18:13:18:59,3352,咨询,供水热线的号码82302284386,2003-04-18:13:19:01,3142,建议,增设公交线路
接受导入数据的表名是 CALLS，表结构如下：
Name Null? Type Comment ------------ --------- ------------- ----------------- CALL_ID NOT NULL NUMBER Primary key CALL_DATE NOT NULL DATE Non-unique index EMP_ID NOT NULL NUMBER CALL_TYPE NOT NULL VARCHAR2(12) DETAILS VARCHAR2(25)
逐条数据插入INSERT
数据导入的最简单方法就是编写 INSERT 语句，将数据逐条插入数据库。这种方法只适合导入少量数据，如 sql*Plus 脚本创建某个表的种子数据。该方法的最大缺点就是导入速度缓慢，占用了大量的 CPU 处理时间，不适合大批量数据的导入；而其主要优点就是导入构思简单又有修改完善的弹性，不需要多做其它的准备就可以使用。如果你有很多时间没法打发，又想折磨一下数据库和 CPU，那这种方法正适合你。:)
为了与其它方法做比较，现将十万条记录通过此方法导入到 CALLS 表中，总共消耗 172 秒，其中导入进程占用 CPU 时间为 52 秒。
逐条数据插入 INSERT，表暂无索引
为什么上一种方法占用了较多的 CPU 处理时间，关键是 CALLS 表中已创建了索引，当一条数据插入到表中时，Oracle 需要判别新数据与老数据在索引方面是否有冲突，同时要更新表中的所有索引，重复更新索引会消耗一定的时间。因此提高导入速度的好办法就是在创建表时先不创建索引或者在导入数据之前删除所有索引，在外部文件数据逐条插入到表中后再统一创建表的索引。这样导入速度会提高，同时创建的索引也很紧凑而有效，这一原则同样适用于位图索引（Bitmap Index）。对于主要的和唯一的关键约束(key constraints)，可以使之先暂时失效(disabling)或者删除约束来获得同样的效果，当然这些做法会对已经存在的表的外键约束产生相关的影响，在删除前需要通盘斟酌。
需要说明的是，这种方法在表中已存在很多数据的情况下不太合适。例如表中已有九千万条数据，而此时需要追加插入一千万条数据，实际导入数据节省的时间将会被重新创建一亿条数据的索引所消耗殆尽，这是我们不希望得到的结果。但是，如果要导入数据的表是空的或导入的数据量比已有的数据量要大得多，那么导入数据节省的时间将会少量用于重新创建索引，这时该方法才可以考虑使用。
加快索引创建是另一个需要考虑的问题。为了减少索引创建中排序的工作时间，可以在当前会话中增加 SORT_AREA_SIZE 参数的大小，该参数允许当前会话在内存的索引创建过程中执行更多的排序操作。同样还可以使用 NOLOGGING 关键字来减少因创建索引而生成的 REDO 日志量，NOLOGGING 关键字会对数据库的恢复和 Standby 备用数据库产生明显的影响，所以在使用之前要仔细斟酌，到底是速度优先还是稳定优先。
运用这种方法，先删除 CALLS 表的主键和不唯一的索引，然后逐条导入数据，完成后重新创建索引( 表在导入数据前是空的)。该方法总共消耗 130 秒，包括重建索引的时间，其中导入进程占用 CPU 时间为 35秒。
这种方法的优点是可以加快导入的速度并使索引更加紧凑有效；缺点是缺乏通用性，当你对表增加新的复杂的模式元素（索引、外键等）时你需要添加代码、修改导入执行程序。另外针对 7*24 在线要求的数据库在线导入操作时，删除表的索引会对在线用户的查询有很大的性能影响，同时也要考虑，主要或唯一的关键约束条件的删除或失效可能会影响到引用它们的外键的使用。
批量插入，表暂无索引
在Oracle V6 中 OCI 编程接口加入了数组接口特性。数组操作允许导入程序读取外部文件数据并解析后，向数据库提交SQL语句，批量插入 SQL 语句检索出的数据。Oracle 仅需要执行一次 SQL 语句，然后在内存中批量解析提供的数据。批量导入操作比逐行插入重复操作更有效率，这是因为只需一次解析 SQL 语句，一些数据绑订操作以及程序与数据库之间来回的操作都显着减少，而且数据库对每一条数据的操作都是重复可知的，这给数据库提供了优化执行的可能。其优点是数据导入的总体时间明显减少，特别是进程占用 CPU 的时间。
需要提醒的是，通过 OCI 接口确实可以执行数据批量导入操作，但是许多工具和脚本语言却不支持使用此功能。如果要使用该方法，需要研究你所使用的开发工具是否支持 OCI 批量操作功能。导入程序需要进行复杂的编码并可能存在错误的风险，缺乏一定的弹性。
运用上述方法，程序将外部数据提取到内存中的数组里，并执行批量插入操作（100行/次），保留了表的删除/重建索引操作，总的导入时间下降到 14 秒，而进程占用 CPU 的时间下降到7秒，可见实际导入数据所花费的时间显着下降了 95%。
CREATE TABLE AS SELECT，使用Oracle9i的External Table
Oracle 9i 的一项新特性就是 External Table，它就象通常的数据库表一样，拥有字段和数据类型约束，并且可以查询，但是表中的数据却不存储在数据库中，而是在与数据库相关联的普通外部文件里。当你查询 External Table 时，Oracle 将解析该文件并返回符合条件的数据，就象该数据存储在数据库表中一样。
需要注意的是，你可以在查询语句中将 External Table 与数据库中其他表进行连接（Join），但是不能给 External Table 加上索引，并且不能插入/更新/删除数据，毕竟它不是真正的数据库表。另外，如果与数据库相关联的外部文件被改变或者被删除，这会影响到 External Table 返回查询结果，所以在变动前要先跟数据库打招呼。
这种方法为导入数据打开了新的一扇门。你可以很容易的将外部文件与数据库相关联，并且在数据库中创建对应的 External Table，然后就可以立即查询数据，就象外部数据已经导入到数据库表中一样。唯一的不足需要明确，数据并未真正导入到数据库中，当外部文件被删除或覆盖时，数据库将不能访问 External Table 里的数据，而且索引没有被创建，访问数据速度将有所缓慢。创建 CALLS_EXTERNAL（External Table表）如下，使之与外部数据文件关联：
CREATE TABLE calls_external (call_id NUMBER, call_date DATE, emp_id NUMBER, call_type VARCHAR2(12), details VARCHAR2(25)) ORGANIZATION EXTERNAL (TYPE oracle_loader DEFAULT DIRECTORY extract_files_dir ACCESS PARAMETERS (RECORDS DELIMITED BY NEWLINE FIELDS TERMINATED BY ',' MISSING FIELD VALUES ARE NULL (call_id, call_date CHAR DATE_FORMAT DATE MASK "yyy-mm-dd:hh24:mi:ss", emp_id, call_type, details ) ) LOCATION ('calls.dat') );
然后将 External Table 与真正被使用的表 CALLS 关联同步，删除 CALLS 表并重建它：
CREATE TABLE calls ( call_id NUMBER NOT NULL, call_date DATE NOT NULL, emp_id NUMBER NOT NULL, call_type VARCHAR2(12) NOT NULL, details VARCHAR2(25) ) TABLESPACE tbs1 NOLOGGING AS SELECT call_id, call_date, emp_id, call_type, details FROM calls_external;
因为 CALLS 表是真正的数据库表，可以创建索引来加快访问，表中的数据将被保留，即使外部数据文件被更新或被删除。在建表语句中NOLOGGING关键字用于加快索引重建。
运用这种方法导入数据，总的导入时间为 15 秒，进程占用 CPU 的时间为8秒，这比前一种方法稍微慢些，但不能就此认为使用 External Table 导入数据一定比 OCI 批量插入慢。
这种方法的优点是，未经进行大量的编写代码就取得了不错的结果，不象 OCI 批量插入存在编码错误风险，它还可以使用 dbms_job 包调度数据导入进程，实现数据导入的自动化。其缺点是目标表必须先删除后重建，如果只需要导入增量数据时此方法就不合适了，另外用户在表的重建过程中访问数据时会遇到 "table or view does not exist" 的错误，它仅适用于 Oracle 9i 以上版本的数据库。
INSERT Append as SELECT，使用 Oracle9i 的 External Table
上一种方法演示了如何创建与外部数据文件关联的数据库表，其表的数据是由外部数据文件映射过来。缺点是数据库表需要被先删除再重建来保持与外部数据文件的一致和同步，对导入增量的数据而不需要删除已有数据的情况不合适。针对这种需求，Oracle 提供了 INSERT 语句外带 APPEND 提示来满足。
INSERT /*+ APPEND */ INTO calls (call_id, call_date, emp_id, call_type, details) SELECT call_id, call_date, emp_id, call_type, details FROM calls_external;
该语句读取引用外部数据文件的 CALLS_EXTERNAL 表中内容，并将之增加到表 CALLS 中。Append 提示告诉 Oracle 使用快速机制来插入数据，同时可以配合使用表的 NOLOGGING 关键字。
可以预见这种方法与前一方法消耗了相同的时间，毕竟它们是使用 External Table 特性导入数据的不同阶段解决方法。如果目标表不是空的，那将会消耗稍微长的时间（因为要重建更长的索引），而前一 CREATE TABLE as SELECT 方法是整体创建索引。
SQL*Loader的强大功能
SQL*Loader 是 Oracle 提供的导入实用程序，特别针对从外部文件导入大批量数据进入数据库表。该工具已经有多年的历史，每一次版本升级都使其更加强大、灵活和快捷，但遗憾的是它的语法却是神秘而不直观，并且只能从命令行窗口处进行调用。
尽管它有不直观的缺点，但却是最快最有效的导入数据方法。缺省情况下它使用 "conventional path" 常规选项来批量导入数据，其性能提高度并不明显。我建议使用更快速的导入参数选项，在命令行添加"direct=true" 选项调用 "direct path" 导入选项。在 "direct path" 导入实现中，程序在数据库表的新数据块的 high water mark 处直接写入导入数据，缩短了数据插入的处理时间，同时优化使用了非常有效的B+二叉树方法来更新表的索引。
运用这种方法，如果使用缺省的 conventional path 导入选项，总的导入时间是 81 秒，进程占用 CPU 时间大约是 12 秒，这包括了更新表的索引时间。如果使用 direct path 导入选项，总的导入时间竟是 9 秒，进程占用 CPU 时间也仅仅是 3 秒，也包括了更新表的索引时间。
由此可见，尽管表中的索引在数据导入之前并没有被删除，使用SQL*Loader的direct path 导入选项仍然是快速和有效的。当然它也有缺点，就像NOLOGGING关键字一样该方法不生成REDO日志数据，导入进程出错后将无法恢复到先前状态；在数据导入过程中表的索引是不起作用的，用户此时访问该表时将出现迟缓，当然在数据导入的过程中最好不要让用户访问表。
分区交换 (Partition Exchange)
以上讨论的数据导入方法都有一个限制，就是要求用户在导入数据完成之后才可以访问数据库表。面对7×24不间断访问数据库来说，如果我们只是导入需要增加的数据时，这种限制将对用户的实时访问产生影响。Oracle在这方面提供了表分区功能，它可以减少导入数据操作对用户实时访问数据的影响，操作模式就象使用可热插拔的硬盘一样，只不过这里的硬盘换成了分区（Partition）而已。需要声明的是 Partitioning 分区功能只有在企业版数据库中才提供。
在一个被分区过的表中，呈现给用户的表是多个分区段（segments）的集合。分区可以在需要时被添加，在维护时被卸载或删除，分区表可以和数据库中的表交换数据，只要它们的表结构和字段类型是一致的，交换后的分区表将拥有与之互动的表的数据。需要注意的是，这种交换只是在Oracle数据库的数据字典层面上进行，并没有数据被实际移动，所以分区表交换是极其快速的。
为了创建实验环境，先假设CALLS表是个分区表，要创建一个空的分区PART_01012004，用来保存2004年1月1日的呼叫数据。然后需要再创建一临时表为CALLS_TEMP，该表与CALLS表拥有相同的字段和数据类型。
我们使用先前介绍的导入方法将十万条数据导入到CALLS_TEMP表中，可以耐心等待数据完全导入到CALLS_TEMP表中，并且创建好索引和相关约束条件，所有这一切操作并不影响用户实时访问CALLS表，因为我们只对CALLS_TEMP临时表进行了操作。一旦数据导入完成，CALLS_TEMP表就存有2004年1月1日的呼叫数据。同时利用CALLS表中名为PART_01012004的空分区，使用如下语句执行分区交换：
ALTER TABLE calls EXCHANGE PARTITION part_01012004 WITH TABLE calls_temp INCLUDING INDEXES WITHOUT VALIDATION;
分区交换操作将非常快速地只更新CALLS表的数据字典，PART_01012004分区表即刻拥有CALLS_TEMP表的所有数据，而CALLS_TEMP表变为空表。假定CALLS表使用局部索引而非全局索引，上述语句中的INCLUDING INDEXES将保证分区交换包括索引的可用性，WITHOUT VALIDATION 指明不检查交替表中数据的匹配，加快了交换的速度。
结论
以上探讨了Oracle数据库的多种数据导入方法，每种方法都有其优缺点和适用环境，能够满足你不同的导入需求，当然你需要在了解了这些方法后，在速度、简易性、灵活性、可恢复性和数据可用性之间寻求最佳导入方案。
为了对比各种方法的效果，我们创建了一个实例来展示各种方法的导入效率和效果，从中你可以选择最适合的方法用于今后的数据导入工作。同时请记住，本文并未囊括所有的ORACLE数据导入技术（比如并行数据导入技术），这需要我们继续不懈的探索和尝试。
⑵ 如何加快数据库连接速度
1、升级硬件
2、根据查询条件,建立索引,优化索引、优化访问方式，限制结果集的数据量。
3、扩大服务器的内存
4、增加服务器CPU个数
5、对于大的数据库不要设置数据库自动增长，它会降低服务器的性能
6、在查询Select语句中用Where字句限制返备滚回的行数,避免表扫描,如果返回不必要的数据，浪费了服务器的I/O资源，加重了网络的负担降低性能。如果仿逗余表很大，在表扫描的期间将表锁住，禁止其他的联接访问表,后果严重。
7、查询时不要返回不指世需要的行、列
8、用select
top
100
/
10
Percent
来限制用户返回的行数或者SET
ROWCOUNT来限制操作的行
9、在IN后面值的列表中，将出现最频繁的值放在最前面，出现得最少的放在最后面，减少判断的次数
10、一般在GROUP
BY
个HAVING字句之前就能剔除多余的行，所以尽量不要用它们来做剔除行的工作。他们的执行顺序应该如下最优：
select的Where字句选择所有合适的行，Group
By用来分组个统计行，Having字句用来剔除多余的分组。这样Group
By
个Having的开销小，查询快.对于大的数据行进行分组和Having十分消耗资源。如果Group
BY的目的不包括计算，只是分组，那么用Distinct更快
11、一次更新多条记录比分多次更新每次一条快,就是说批处理好.
⑶ 如何使insert插入速度提升
1、搞清楚数枯你的数据库允许的最大并发连接数P
2、搞清楚你当前程档销序和你数据库之间带宽限制B
3、搞清楚你当前一条记录所用薯蠢洞的数据量大小Q
4、用公式X = MIN(B/Q, P)得到允许并发线程数X
5、用并发线程去插入数据，速度最多会得到X倍提高
⑷ 十万条数据，如何一次性插入数据库，才能保证效率
您好.
要提高插入效率，孙档比较多的建议无非就是：
1、插入前删除索引，插入搏乱后重建；
2、把表设为不记录日志；
3、调整某些参数，让数据库的页空间尽量的大，以避免过多的I/O操作；
对于一个通过基凯档用户界面上传数据的项目来说，只有3还有可行之处。不记录日志似乎可行，但commit之后的性能问题，实在让人担心。
⑸ 如何提高Oracle数据库的插入速度
1、alter table tb nologging --若基丛是归档模式下，将表设置为不记录日志
2、旦闹drop index index_name.....--若表上有index，先删除表上的index
3、insert /*+append*/模锋罩 into tb ..... --执行插入
4、create index index_name on .....--重建index
5、alter table tb logging --回复日志记录功能
⑹ 怎么提高Mysql执行sql导入的速度
1、如果mysql的data数据很少，内存足够大，可以把data防止到内存盘中。
linux如下设置内存盘：
mount -t ramfs none /ram
默认使用内存一半
如果内存不够大，系统有多个硬盘，则把mysql应用程序和data目录分开到不同硬盘上。
2、mysql的表设置为myiasm，比同等条件下的innodb能快20倍以上
3、导入完成以后才创建数据库索引
4、导入完成以后根据需要转换为其他engine，比如innodb
5、多条数据插入一个表，可以使用多记录方式：
insert into tablename values(’xxx’,'xxx’),(’yyy’,'yyy’)…;
6、如果多个mysql执行导入，可以使用delayed
insert delayed into tablename values(’sss’,’ssss’);
7、大文件sql文件可以用split分成多份再导
8、同等条件下，redhat比ubuntu强很多（几乎肯定）
⑺ 如何优化mysql写入速
单机MySQL数据库的优化
一、服务器硬件对MySQL性能的影响
①磁盘寻道能力 （磁盘I/O），我们现在上的都是SAS15000转的硬盘。MySQL每秒钟都在进行大量、复杂的查询操作，对磁盘的读写量可想而知。所以，通常认为磁 盘I/O是制约MySQL性能的最大因素之一，对于日均访 问量在100万PV以上的Discuz!论坛，由于磁盘I/O的制约，MySQL的性能会非常低下！解决这一制约因素可以考虑以下几种解决方案： 使用RAID1+0磁盘阵列，注意不要尝试使用RAID-5，MySQL在RAID-5磁盘阵列上的效率不会像你期待的那样快。
②CPU 对于MySQL应用，推荐使用DELL R710，E5620 @2.40GHz（4 core）* 2 ，我现在比较喜欢DELL R710，也在用其作Linuxakg 虚拟化应用；
③物理内存对于一台使用MySQL的Database Server来说，服务器内存建议不要小于2GB，推荐使用4GB以上的物理内存，不过内存对于现在的服务器而言可以说是一个可以忽略的问题，工作中遇到高端服务器基本上内存都超过了32G。
我们工作中用得比较多的数据库服务器是HP DL580G5和DELL R710，稳定性和性能都不错；特别是DELL R710，我发现许多同行都是采用它作数据库的服务器，所以重点推荐下。
二、MySQL的线上安装我建议采取编译安装的方法，这样性能上有较大提升，服务器系统我建议用64bit的Centos5.5，源码包的编译参数会默 认以Debgu模式生成二进制代码，而Debug模式给MySQL带来的性能损失是比较大的，所以当我们编译准备安装的产品代码时，一定不要忘记使用“— without-debug”参数禁用Debug模式。而如果把—with-mysqld-ldflags和—with-client-ldflags二 个编译参数设置为—all-static的话，可以告诉编译器以静态方式编译和编译结果代码得到最高的性能。使用静态编译和使用动态编译的代码相比，性能 差距可能会达到5%至10%之多。我参考了简朝阳先生的编译参数，特列如下，供大家参考
./configure –prefix=/usr/local/mysql –without-debug –without-bench –enable-thread-safe-client –enable-assembler –enable-profiling –with-mysqld-ldflags=-all-static –with-client-ldflags=-all-static –with-charset=latin1 –with-extra-charset=utf8,gbk –with-innodb –with-csv-storage-engine –with-federated-storage-engine –with-mysqld-user=mysql –without-我是怎么了ded-server –with-server-suffix=-community –with-unix-socket-path=/usr/local/mysql/sock/mysql.sock
三、MySQL自身因素当解决了上述服务器硬件制约因素后，让我们看看MySQL自身的优化是如何操作的。对 MySQL自身的优化主要是对其配置文件my.cnf中的各项参数进行优化调整。下面介绍一些对性能影响较大的参数。
下面，根据以上硬件配置结合一份已经优化好的my.cnf进行说明：
#vim /etc/my.cnf
以下只列出my.cnf文件中[mysqld]段落中的内容，其他段落内容对MySQL运行性能影响甚微，因而姑且忽略。
[mysqld]
port = 3306
serverid = 1
socket = /tmp/mysql.sock
skip-locking
#避免MySQL的外部锁定，减少出错几率增强稳定性。
skip-name-resolve
#禁止MySQL对外部连接进行DNS解析，使用这一选项可以消除MySQL进行DNS解析的时间。但需要注意，如果开启该选项，则所有远程主机连接授权都要使用IP地址方式，否则MySQL将无法正常处理连接请求！
back_log = 384
#back_log参数的值指出在MySQL暂时停止响应新请求之前的短时间内多少个请求可以被存在堆栈中。 如果系统在一个短时间内有很多连接，则需要增大该参数的值，该参数值指定到来的TCP/IP连接的侦听队列的大小。不同的操作系统在这个队列大小上有它自 己的限制。 试图设定back_log高于你的操作系统的限制将是无效的。默认值为50。对于Linux系统推荐设置为小于512的整数。
key_buffer_size = 384M
#key_buffer_size指定用于索引的缓冲区大小，增加它可得到更好的索引处理性能。对于内存在4GB左右的服务器该参数可设置为256M或384M。注意：该参数值设置的过大反而会是服务器整体效率降低！
max_allowed_packet = 4M
thread_stack = 256K
table_cache = 614K
sort_buffer_size = 6M
#查询排序时所能使用的缓冲区大小。注意：该参数对应的分配内存是每连接独占，如果有100个连接，那么实际分配的总共排序缓冲区大小为100 × 6 ＝ 600MB。所以，对于内存在4GB左右的服务器推荐设置为6-8M。
read_buffer_size = 4M
#读查询操作所能使用的缓冲区大小。和sort_buffer_size一样，该参数对应的分配内存也是每连接独享。
join_buffer_size = 8M
#联合查询操作所能使用的缓冲区大小，和sort_buffer_size一样，该参数对应的分配内存也是每连接独享。
myisam_sort_buffer_size = 64M
table_cache = 512
thread_cache_size = 64
query_cache_size = 64M
#指定MySQL查询缓冲区的大小。可以通过在MySQL控制台观察，如果Qcache_lowmem_prunes的值非常大，则表明经常出现缓冲不 够 的情况；如果Qcache_hits的值非常大，则表明查询缓冲使用非常频繁，如果该值较小反而会影响效率，那么可以考虑不用查询缓 冲；Qcache_free_blocks，如果该值非常大，则表明缓冲区中碎片很多。
tmp_table_size = 256M
max_connections = 768
#指定MySQL允许的最大连接进程数。如果在访问论坛时经常出现Too Many Connections的错误提 示，则需要增大该参数值。
max_connect_errors = 1000
wait_timeout = 10
#指定一个请求的最大连接时间，对于4GB左右内存的服务器可以设置为5-10。
thread_concurrency = 8
#该参数取值为服务器逻辑CPU数量*2，在本例中，服务器有2颗物理CPU，而每颗物理CPU又支持H.T超线程，所以实际取值为4*2=8；这个目前也是双四核主流服务器配置。
skip-networking
#开启该选项可以彻底关闭MySQL的TCP/IP连接方式，如果WEB服务器是以远程连接的方式访问MySQL数据库服务器则不要开启该选项！否则将无法正常连接！
table_cache=1024
#物理内存越大，设置就越大。默认为2402,调到512-1024最佳
innodb_additional_mem_pool_size=4M
#默认为2M
innodb_flush_log_at_trx_commit=1
#设置为0就是等到innodb_log_buffer_size列队满后再统一储存，默认为1
innodb_log_buffer_size=2M
#默认为1M
innodb_thread_concurrency=8
#你的服务器CPU有几个就设置为几，建议用默认一般为8
key_buffer_size=256M
#默认为218，调到128最佳
tmp_table_size=64M
#默认为16M，调到64-256最挂
read_buffer_size=4M
#默认为64K
read_rnd_buffer_size=16M
#默认为256K
sort_buffer_size=32M
#默认为256K
thread_cache_size=120
#默认为60
query_cache_size=32M
※值得注意的是：
很多情况需要具体情况具体分析
一、如果Key_reads太大，则应该把my.cnf中Key_buffer_size变大，保持Key_reads/Key_read_requests至少1/100以上，越小越好。
二、如果Qcache_lowmem_prunes很大，就要增加Query_cache_size的值。
很多时候我们发现，通过参数设置进行性能优化所带来的性能提升，可能并不如许多人想象的那样产生质的飞跃，除非是之前的设置存在严重不合理的情况。我们 不能将性能调优完全依托于通过DBA在数据库上线后进行的参数调整，而应该在系统设计和开发阶段就尽可能减少性能问题。
【51CTO独家特稿】如果单MySQL的优化始终还是顶不住压力时，这个时候我们就必须考虑MySQL的高可用架构（很多同学也爱说成是MySQL集群）了，目前可行的方案有：
一、MySQL Cluster
优势：可用性非常高，性能非常好。每份数据至少可在不同主机存一份拷贝，且冗余数据拷贝实时同步。但它的维护非常复杂，存在部分Bug，目前还不适合比较核心的线上系统，所以这个我不推荐。
二、DRBD磁盘网络镜像方案
优势：软件功能强大，数据可在底层快设备级别跨物理主机镜像，且可根据性能和可靠性要求配置不同级别的同步。IO操作保持顺序，可满足数据库对数据一致 性的苛刻要求。但非分布式文件系统环境无法支持镜像数据同时可见，性能和可靠性两者相互矛盾，无法适用于性能和可靠性要求都比较苛刻的环境，维护成本高于 MySQL Replication。另外，DRBD也是官方推荐的可用于MySQL高可用方案之一，所以这个大家可根据实际环境来考虑是否部署。
三、MySQL Replication
在实际应用场景中，MySQL Replication是使用最为广泛的一种提高系统扩展性的设计手段。众多的MySQL使用者通过Replication功能提升系统的扩展性后，通过 简单的增加价格低廉的硬件设备成倍 甚至成数量级地提高了原有系统的性能，是广大MySQL中低端使用者非常喜欢的功能之一，也是许多MySQL使用者选择MySQL最为重要的原因。
比较常规的MySQL Replication架构也有好几种，这里分别简单说明下
MySQL Replication架构一：常规复制架构--Master-slaves，是由一个Master复制到一个或多个Salve的架构模式，主要用于读压力大的应用数据库端廉价扩展解决方案，读写分离，Master主要负责写方面的压力。
MySQL Replication架构二：级联复制架构，即Master-Slaves-Slaves,这个也是为了防止Slaves的读压力过大，而配置一层二级 Slaves，很容易解决Master端因为附属slave太多而成为瓶劲的风险。
MySQL Replication架构三：Dual Master与级联复制结合架构，即Master-Master-Slaves，最大的好处是既可以避免主Master的写操作受到Slave集群的复制带来的影响，而且保证了主Master的单点故障。
以上就是比较常见的MySQL replication架构方案，大家可根据自己公司的具体环境来设计 ，Mysql 负载均衡可考虑用LVS或Haproxy来做，高可用HA软件我推荐Heartbeat。
MySQL Replication的不足：如果Master主机硬件故障无法恢复，则可能造成部分未传送到slave端的数据丢失。所以大家应该根据自己目前的网络 规划，选择自己合理的Mysql架构方案，跟自己的MySQL DBA和程序员多沟涌，多备份（备份我至少会做到本地和异地双备份），多测试，数据的事是最大的事，出不得半点差错，切记切记。
⑻ mysql怎么提高insert into的速度啊
sql语句中，添加记录的语法为：insert into 表名 （col1，col2....coln）values(value1,value2.....valuen)；
其中，如果你插入的每一列都是顺序插入，无一缺漏的话，（col1，col2...coln）可以省略。
也就是上式也可以简化为：insert into 表名values(value1,value2.....valuen)；
看了你写的sql代码，问题出在insert into 的整体语句出现在了不该出现的地方，只需做一点小改动即可解决，如下图：
解析：insert into语句需要在user表已经存在的情况下才可以使用。而你原来的语句中，橡誉将上图2中的语句插入到了create table user的语句中，致使create table user 语句未能成功执行，所以才会报错。
而将“INSERT INTO user(uid,tel) values('甲','3354986');”整条语句直接拿出来放在“ENGINE=InnoDB DEFAULT CHARSET=gbk;”后面之后，整个sql就可以顺利执行了。
(8)提高插入数据库的速度扩展阅读：
当mysql大批量插入数据的时候就会变的非常慢,mysql提高insert into 插入速度的方法有三种:
1、第一种插入提速方法:
如果数据库中的数据已经很多(几百万条), 那么可以加大mysql配置中的 bulk_insert_buffer_size，这个参数默认为8M
举例：bulk_insert_buffer_size=100M；
2、第二种mysql插入提速方法:
改写所有 insert into 语句为insertdelayed into
这个insert delayed不同之处在于：立即返回结果，后台进行处理租拦插入。
3、第三个方法: 一次插入多条数据:
insert中插入多条数据，举例:
insert into table values('11','11'),('22'梁型段,'22'),('33','33')...;
⑼ 如何提高mysql 的插入速度，高手请帮忙
加快MySQL插入速度可循下列手段去做：
1）数据表使用尽量少的索引；
2）合理设计表结构、尽量插入冗余量较小的信息嫌猜，避免插入多余、重复和无用的信息；
3）尽量减少应用程序与数据库之间的网络往返量（如使用存储过程等）；
4）数据表使用MyISAM存储引擎替代默认的InnoDB存储引擎伍者或。在不需要支持事务的情况下，MyISAM引擎表的插入速度要远高于InnoDB引擎表，因为前者不需要增加额外的事务、回滚和崩溃修复等系统开销，自然插入速度要比后者迅速的多；
5）减少并腔伍发量、提升硬件。
⑽ 高分 求助 向oracle 数据库 怎么插入数据 使查询时速度快
逐条数据插入INSERT
数据导入的最简单方法就是编写 INSERT 语句，将数据逐条插入数据库。这种方法只适合导缓哪入少量数据，如 SQL*Plus 脚本创建某个表的种子扰缓码数据。该方法的最大缺点就是导入速度缓慢，占用了大量的 CPU 处理时间，不适合大批量数据的导入；而其主要优点就是导入构思简单又有修改完善的弹性，不需要多做其它的准备就可以使用。如果你有很多时间没法打发，又想折磨一下数据库和 CPU，那这种方法正适合你。
为了与其它方法做比较，现将十万条记录通过此方法导入到 CALLS 表中，总共消耗 172 秒，其中导入进程占用 CPU 时间为 52 秒。
逐条数据插入 INSERT，表暂无索引
为什么上一种方法占用了较多的 CPU 处理时间，关键是 CALLS 表中已创建了索引，当一条数据插入到表中时，Oracle 需要判别新数据与老数据在索引方面是否有冲突，同时要更新表中的所有索引，重复更新索引会消耗一定的时间。因此提高导入速度的好办法就是在创建表时先不创建索引或者在导入数据之前删除所有索引，在外部文件数据逐条插入到表中后再统一创建表的索引。这样导入速度会提高，同时创建的索引也很紧凑而有效，这一原则同样适用于位图索引（Bitmap Index）。对于主要的和唯一的关键约束(key constraints)，可以使之先暂时失效(disabling)或者删除约束来获得同样的效果，当然这些做法会对已经存在的表的外键约束产生相关的影响，在删除前需要通盘斟酌。
需要说明的是，这种方法在表中已存在很多数据的情况下不太合适。例如表中已有九千万条数据，而此时需要追加插入一千万条数据，实际导入数据节省的时间将会被重新创建一亿条数据的索引所消耗殆尽，这是我们不希望得到的结果。但是，如果要导入数据的表是空的或导入的数据量比已有的数据量要大得多，那么导入数据节省的时间将会少量用于重新创建索引，这时该方法才可以考虑使用。 加快索引创建是另一个需要考虑的问题。为了减少索引创建中排序的工作时间，可以在当前会话中增加 SORT_AREA_SIZE 参数的大小，该参数允许当前会话在内存的索引创建过程中执行更多的排序操作。同样还可以使用 NOLOGGING 关键字来减少因创建索引而生成的 REDO 日志量，NOLOGGING 关键字会对数据库的恢复和 Standby 备用数据库产生明显的影响，所以在使用之前要仔细斟酌，到底是速度优先还是稳定优先。
运用这种方法，先删除 CALLS 表的主键和不唯一的索引，然后逐条导入数据，完成后重新创建索引( 表在导入数据前是空的)。该方法总共消耗 130 秒，包括重建索引的时间，其中导入进程占用 CPU 时间为 35秒。
这种方法的优点是可以加快导入的速度并使索引更加紧凑有效；缺点是缺乏通用性，当你对表增加新的复杂的模式元素（索引、外键等）时你需要添加代码、修改导入执行程序。另外针对 7*24 在线要求的数据库在线导入操作时，删除表的索引会对在线用户的查询有很大的性能影响，同时也要考虑，主要或唯一的关键约束条件的删除或失效可能会影响到引用它们的外键的使用。
批量插入，表暂无索引
在Oracle V6 中 OCI 编程接口加入了数组接口特性。数组哪盯操作允许导入程序读取外部文件数据并解析后，向数据库提交SQL语句，批量插入 SQL 语句检索出的数据。Oracle 仅需要执行一次 SQL 语句，然后在内存中批量解析提供的数据。批量导入操作比逐行插入重复操作更有效率，这是因为只需一次解析 SQL 语句，一些数据绑订操作以及程序与数据库之间来回的操作都显着减少，而且数据库对每一条数据的操作都是重复可知的，这给数据库提供了优化执行的可能。其优点是数据导入的总体时间明显减少，特别是进程占用 CPU 的时间。
需要提醒的是，通过 OCI 接口确实可以执行数据批量导入操作，但是许多工具和脚本语言却不支持使用此功能。如果要使用该方法，需要研究你所使用的开发工具是否支持 OCI 批量操作功能。导入程序需要进行复杂的编码并可能存在错误的风险，缺乏一定的弹性。
运用上述方法，程序将外部数据提取到内存中的数组里，并执行批量插入操作（100行/次），保留了表的删除/重建索引操作，总的导入时间下降到 14 秒，而进程占用 CPU 的时间下降到7秒，可见实际导入数据所花费的时间显着下降了 95%。