⑴ 如何提高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%。