Mysql数据库优化技术之配置篇、索引篇 （ 必看 必看 转）
對于可以靜態化的頁面，盡可能靜態化
對一個動態頁面中可以靜態的局部，采用靜態化
部分數據可以生成XML，或者文本文件形式保存
使用數據緩存技術，例如： MemCached
(二)優化的檢測方法
1.用戶體驗檢測
2.Mysql狀態檢測
在Mysql命令行里面使用show status命令，得到當前mysql狀態。
主要關注下列屬性：
key_read_requests (索引讀的請求數）(key_buffer_size設置影響)
key_reads（索引讀響應數)
Key_blocks_used
Qcache_*
Open_tables(通過table_cache的設置影響)
Opened_tables
table_locks
3. 第三方工具檢測
mysqlreporthttp://hackmysql.com/mysqlreport
mytophttp://jeremy.zawodny.com/mysql/mytop/
系統及Mysql的Log
系統命令： top, sar
Mysql的Log: slow_query.log
(三)硬件方面的優化
硬件方面，最容易成為Mysql瓶頸的部分是磁盤，其次是CPU和內存
磁盤方面
使用更快的磁盤，會對Mysql有很好的幫助
使用更多的硬盤，通過Raid，可以提高單塊磁盤速度的問題
對于Raid方式，建議采用Raid 0+1 或者 Raid 1+0
CPU
毫無疑問，更高主頻的CPU和更多的CPU數量可以給Mysql更
高的性能
內存
更高的內存，往往可以讓Mysql中的更多的數據緩存在內存中，
但是，一個重要的因素是，需要有正確的Mysql的配置
網卡
使用千兆網卡及千兆網絡
(四)操作系統方面的優化
1.不使用交換區。如果內存不足，增加更多的內存或配置你的系統使用較少內存
2. 不要使用NFS磁盤
3.增加系統和MySQL服務器的打開文件數量
使用ulimit –n 65535
4.增加系統的進程和線程數量。
5.關閉不必要的應用，優化硬盤參數，使用hdparm測試
(五)應用級的優化
1.使用多服務器負載均衡(多臺讀和寫,用復制技術進行數據同步)
2.表的分區 (自定義分區,mysql5.1開始支持自帶分區功能)
3.使用數據緩存技術memcached
(六)Mysql配置的優化
1.key_buffer(=512):索引緩沖使用的內存數量
這對MyISAM表來說非常重要,設定在可用內存的25%-30%較好,通過檢查狀態值 Key_read_requests和 Key_reads,
可以知道key_buffer設置是否合理。比例key_reads / key_read_requests應該盡可能的低，至少是1:100，1:1000更好 ,否則說明 key_buffer 設置有點偏小
2.innodb_buffer_pool_size(= 512):索引緩沖使用的內存數量
3.table_cache (=1024):數據表緩存區的尺寸
每當 MySQL 訪問一個表時，如果在表緩沖區中還有空間，該表就被打開并放入其中，這樣可以更快地訪問表內容。
通過檢查運行峰值時間的 Open_tables 和 Opened_tables 狀態值，可以決定是否需要調整 table_cache 的值。
如果你發現 open_tables 的值等于 table_cache，并且發現 opened_tables 狀態值在不斷增長，那么你就需要增加 table_cache 參數值了,
也不能盲目地把 table_cache 參數設置成很大的值，如果設置得太高，可能會造成文件描述符不足，從而造成性能不穩定或者連接失敗。
4.sort_buffer_size (=256):指定排序用緩沖區的長度
該參數對應的分配內存是每連接獨占！如果有100個連接，那么實際分配的總共排序緩沖區大小為100 × 6 ＝ 600MB。
所以，對于內存在4GB左右的服務器推薦設置為6-8M
5.join_buffer_size :關聯查詢用緩沖區的長度
4G內存以上，建議大于32M,該參數對應的分配內存也是每連接獨享！
6.max_connections (=1024):可以復用的線程數量
允許同時連接MySQL服務器的客戶數量 ,可以觀察和估計系統在峰值最大的并發連接數來設置
7.thread_cache(=*):可以復用的線程數量
一般設置為CPU數×2
8.innodb_buffer_pool_size(= 512):innodb表緩存池大小
這對Innodb表來說非常重要。Innodb相比MyISAM表對緩沖更為敏感。MyISAM可以在默認的 key_buffer_size 設置下運行的可以，
然而Innodb在默認的innodb_buffer_pool_size 設置下卻跟蝸牛似的。
由于Innodb把數據和索引都緩存起來，無需留給操作系統太多的內存，因此如果只需要用Innodb的話則可以設置它高達 70-80% 的可用內存。
一些應用于 key_buffer 的規則有 -- 如果你的數據量不大，并且不會暴增，那么無需把innodb_buffer_pool_size 設置的太大了.
9.innodb_flush_logs_at_trx_commit(=1) :事務提交后的日志刷新模式
是否為Innodb比MyISAM慢1000倍而頭大?看來也許你忘了修改這個參數了。默認值是 1，這意味著每次提交的更新事務(或者每個事務之外的語句)都會刷新到磁盤中，
而這相當耗費資源，尤其是沒有電池備用緩存時。很多應用程序，尤其是從 MyISAM轉變過來的那些，把它的值設置為 2 就可以了，也就是不把日志刷新到磁盤上，
而只刷新到操作系統的緩存上。日志仍然會每秒刷新到磁盤中去，因此通常不會丟失每秒1-2次更新的消耗。如果設置為0就快很多了，不過也相對不安全了,
MySQL服務器崩潰時就會丟失一些事務。設置為2指揮丟失刷新到操作系統緩存的那部分事務.
?
?
(七)表的優化
1. 選擇合適的數據引擎
MyISAM:適用于大量的讀操作的表
InnoDB:適用于大量的寫讀作的表
?
2.選擇合適的列類型
使用 SELECT * FROM TB_TEST PROCEDURE ANALYSE()可以對這個表的每一個字段進行分析，給出優化列類型建議
?
3.對于不保存NULL值的列使用NOT NULL，這對你想索引的列尤其重要?
4.建立合適的索引?
5.使用定長字段,速度比變長要快(八)建立索引原則
1.合理使用索引
一個Table在一次query中只能使用一個索引,使用EXPLAIN語句來檢驗優化程序的操作情況
使用analyze幫助優化程序對索引的使用效果做出更準確的預測
2.索引應該創建在搜索、排序、歸組等操作所涉及的數據列上
3.盡量將索引建立在重復數據少的數據列中，唯一所以最好
例如：生日列，可以建立索引，但性別列不要建立索引
4.盡量對比較短的值進行索引
降低磁盤IO操作，索引緩沖區中可以容納更多的鍵值，提高命中率
如果對一個長的字符串建立索引，可以指定一個前綴長度
5.合理使用多列索引
如果多個條件經常需要組合起來查詢,則要使用多列索引(因為一個表一次查詢只能使用一個索引,建立多個單列索引也只能使用一個)
6.充分利用最左前綴
也就是要合理安排多列索引中各列的順序，將最常用的排在前面
7.不要建立過多的索引
只有經常應用于where,order by,group by中的字段需要建立索引.
8.利用慢查詢日志查找出慢查詢(log-slow-queries, long_query_time)
(九)充分利用索引
1.盡量比較數據類型相同的數據列
3.盡可能不對查詢字段加函數,
如WHERE YEAR(date_col) < 1990改造成WHERE date_col < ’1990-01-01’
WHERE TO_DAYS(date_col) - TO_DAYS(CURDATE()) < cutoff 改造成WHERE date_col < DATE_ADD(CURDATE(), INTERVAL cutoff DAY)
(十)SQL語句的優化
1.創建合適的統計中間結果表，降低從大表查詢數據的幾率
2.盡量避免使用子查詢，而改用連接的方式.例如：
SELECT a.id, (SELECT MAX(created) FROM posts WHERE author_id = a.id) AS latest_post
FROM authors a
可以改成：
SELECT a.id, MAX(p.created) AS latest_post
FROM authors AS a
INNER JOIN posts p ON (a.id = p.author_id)
GROUP BY a.id
select song_id from song_lib where singer_id in
(select singer_id from singer_lib
where first_char='A'
) limit 2000改成:
select song_id from song_lib a
inner join singer_lib b on a.singer_id=b.singer_id and first_char='A' limit 2000
3.插入判斷重復鍵時,使用ON DUPLICATE KEY UPDATE :
insert into db_action.action_today(user_id,song_id,action_count) values(1,1,1) ON DUPLICATE KEY UPDATE action_count=action_count+1;
4.避免使用游標
游標的運行效率極低，可以通過增加臨時表，運用多表查詢，多表更新等方式完成任務,不要使用游標.
(十一)使用Explain分析SQL語句使用索引的情況
當 你在一條SELECT語句前放上關鍵詞EXPLAIN，MySQL解釋它將如何處理SELECT，提供有關表如何聯結和以什么次序聯結的信息,借助于 EXPLAIN，可以知道什么時候必須為表加入索引以得到一個使用索引來尋找記錄的更快的SELECT,你也能知道優化器是否以一個最佳次序聯結表。為了 強制優化器對一個SELECT語句使用一個特定聯結次序，增加一個STRAIGHT_JOIN子句。 。
EXPLAIN命令的一般語法是：EXPLAIN <SQL命令> 如：explain select * from a inner join b on a.id=b.id
EXPLAIN的分析結果參數詳解:
1.table：這是表的名字。
2.type：連接操作的類型。
system:表中僅有一條記錄（實際應用很少只有一條資料的表)
const:表最多有一個匹配行,用于用常數值比較PRIMARY KEY或UNIQUE索引的所有部分時,
如：select * from song_lib where song_id=2(song_id為表的primary key)
eq_ref:對于每個來自于前面的表的行組合，從該表中用UNIQUE或PRIMARY KEY的索引讀取一行,
如：select * from song_lib a inner join singer_lib b on a.singer_id=b.singer_id（b的type值為eq_ref)
ref:對于每個來自于前面的表的行組合，從該表中用非UNIQUE或PRIMARY KEY的索引讀取一行
如：select * from song_lib a inner join singer_lib b on a.singer_name=b.singer_name和
select * from singer_lib b where singer_name=‘ccc’ （b的type值為ref,因為b.singer_name是普通索引)
ref_or_null:該聯接類型如同ref，但是添加了MySQL可以專門搜索包含NULL值的行,
如：select * from singer_lib where singer_name=‘ccc’ or singer_name is null
index_merge:該聯接類型表示使用了索引合并優化方法
Key： 它顯示了MySQL實際使用的索引的名字。如果它為空（或NULL），則MySQL不使用索引。
key_len： 索引中被使用部分的長度，以字節計。
3.ref：ref列顯示使用哪個列或常數與key一起從表中選擇行
4.rows： MySQL所認為的它在找到正確的結果之前必須掃描的記錄數。顯然，這里最理想的數字就是1。
5.Extra：這里可能出現許多不同的選項，其中大多數將對查詢產生負面影響。一般有：
using where：表示使用了where條件
using filesort: 表示使用了文件排序,也就是使用了order by子句，并且沒有用到order by 里字段的索引，從而需要
額外的排序開銷，所以如果出現using filesort就表示排序的效率很低，需要進行優化,比如采用強制索引
的方法(force index)
===============================================
mysql 優化 （show variables， show status）。 安裝好mysql后，配制文件應該在/usr /local/mysql/share/mysql目錄中，配制文件有幾個，有my- huge.cnf my-medium.cnf my-large.cnf my-small.cnf,不同的流量的網站和不同配制的服務器環境，當然需要有不同的配制文件了。一般的情 況下，my-medium.cnf這個配制文件就能滿足我們的大多需要；一般我們會把配置文件拷貝到/etc/my.cnf 只需要修改這個配置文件就可以了，使用mysqladmin variables extended-status –u root –p 可以看到目前的參數，有３個配置參數是最重要的，即key_buffer_size,query_cache_size,table_cache。
key_buffer_size只對MyISAM表起作用，
key_buffer_size 指定索引緩沖區的大小，它決定索引處理的速度，尤其是索引讀的速度。一般我們設為16M,實際上稍微大一點的站點 這個數字是遠遠不夠的，通過檢查狀態值 Key_read_requests和Key_reads,可以知道key_buffer_size設置是否合理。比例key_reads / key_read_requests應該盡可能的低，至少是1:100，1:1000更好（上述狀態值可以使用SHOW STATUS LIKE ‘key_read%’獲得）。 或者如果你裝了phpmyadmin 可以通過服務器運行狀態看到,筆者推薦用phpmyadmin管理mysql，以下的狀態值都是本人通過phpmyadmin獲得的實例分析:
這個服務器已經運行了20天
key_buffer_size – 128M
key_read_requests – 650759289
key_reads - 79112
比例接近1:8000 健康狀況非常好
另外一個估計key_buffer_size的辦法 把你網站數據庫的每個表的索引所占空間大小加起來看看以此服務器為例:比較大的幾個表索引加起來大概125M 這個數字會隨著表變大而變大。
從4.0.1開始，MySQL提供了查詢緩沖機制。使用查詢緩沖，MySQL將SELECT語句和查詢結果存放在緩沖區中，今后對于同樣的SELECT語句（區分大小寫），將直接從緩沖區中讀取結果。根據MySQL用戶手冊，使用查詢緩沖最多可以達到238%的效率。
通過調節以下幾個參數可以知道query_cache_size設置得是否合理
Qcache inserts
Qcache hits
Qcache lowmem prunes
Qcache free blocks
Qcache total blocks
Qcache_lowmem_prunes 的值非常大，則表明經常出現緩沖不夠的情況,同時Qcache_hits的值非常大，則表明查詢緩沖使用非常頻繁，此時需要增加緩沖大小 Qcache_hits的值不大，則表明你的查詢重復率很低，這種情況下使用查詢緩沖反而會影響效率，那么可以考慮不用查詢緩沖。此外，在SELECT語 句中加入SQL_NO_CACHE可以明確表示不使用查詢緩沖。
Qcache_free_blocks，如果該值非常大，則表明緩沖區中碎片很多query_cache_type指定是否使用查詢緩沖
我設置:
query_cache_size = 32M
query_cache_type= 1
得到如下狀態值:
Qcache queries in cache 12737 表明目前緩存的條數
Qcache inserts 20649006
Qcache hits 79060095 看來重復查詢率還挺高的
Qcache lowmem prunes 617913 有這么多次出現緩存過低的情況
Qcache not cached 189896
Qcache free memory 18573912 目前剩余緩存空間
Qcache free blocks 5328 這個數字似乎有點大 碎片不少
Qcache total blocks 30953
如果內存允許32M應該要往上加點
table_cache 指定表高速緩存的大小。每當MySQL訪問一個表時，如果在表緩沖區中還有空間，該表就被打開并放入其中，這樣可以更快地訪問表內容。通過檢查峰值時間的 狀態值Open_tables和Opened_tables，可以決定是否需要增加table_cache的值。如果你發現open_tables等于 table_cache，并且opened_tables在不斷增長，那么你就需要增加table_cache的值了（上述狀態值可以使用SHOW STATUS LIKE ‘Open%tables’獲得）。注意，不能盲目地把table_cache設置成很大的值。如果設置得太高，可能會造成文件描述符不足，從而造成性能 不穩定或者連接失敗。
對于有1G內存的機器，推薦值是128－256。
筆者設置table_cache = 256
得到以下狀態:
Open tables 256
Opened tables 9046
雖 然open_tables已經等于table_cache，但是相對于服務器運行時間來說,已經運行了20天，opened_tables的值也非常低。 因此，增加table_cache的值應該用處不大。如果運行了6個小時就出現上述值 那就要考慮增大table_cache。
如果你不 需要記錄2進制log 就把這個功能關掉，注意關掉以后就不能恢復出問題前的數據了，需要您手動備份，二進制日志包含所有更新數據的語句，其目的是在恢復數據庫時用它來把數據盡 可能恢復到最后的狀態。另外，如果做同步復制( Replication )的話，也需要使用二進制日志傳送修改情況。
log_bin指 定日志文件，如果不提供文件名，MySQL將自己產生缺省文件名。MySQL會在文件名后面自動添加數字引，每次啟動服務時，都會重新生成一個新的二進制 文件。此外，使用log-bin-index可以指定索引文件；使用binlog-do-db可以指定記錄的數據庫；使用binlog-ignore- db可以指定不記錄的數據庫。注意的是：binlog-do-db和binlog-ignore-db一次只指定一個數據庫，指定多個數據庫需要多個語 句。而且，MySQL會將所有的數據庫名稱改成小寫，在指定數據庫時必須全部使用小寫名字，否則不會起作用。
關掉這個功能只需要在他前面加上#號
#log-bin
開啟慢查詢日志( slow query log ) 慢查詢日志對于跟蹤有問題的查詢非常有用。它記錄所有查過long_query_time的查詢，如果需要，還可以記錄不使用索引的記錄。下面是一個慢查詢日志的例子：
開啟慢查詢日志，需要設置參數log_slow_queries、long_query_times、log-queries-not-using-indexes。
log_slow_queries 指定日志文件，如果不提供文件名，MySQL將自己產生缺省文件名。long_query_times指定慢查詢的閾值，缺省是10秒。log- queries-not-using-indexes是4.1.0以后引入的參數，它指示記錄不使用索引的查詢。筆者設置 long_query_time=10
筆者設置:
sort_buffer_size = 1M
max_connections=120
wait_timeout =120
back_log=100
read_buffer_size = 1M
thread_cache=32
interactive_timeout=120
thread_concurrency = 4
參數說明:
back_log
要 求MySQL能有的連接數量。當主要MySQL線程在一個很短時間內得到非常多的連接請求，這就起作用，然后主線程花些時間(盡管很短) 檢查連接并且啟動一個新線程。back_log值指出在MySQL暫時停止回答新請求之前的短時間內多少個請求可以被存在堆棧中。只有如果期望在一個短時 間內有很多連接，你需要增加它，換句話說，這值對到來的TCP/IP連接的偵聽隊列的大小。你的操作系統在這個隊列大小上有它自己的限制。 Unix listen(2)系統調用的手冊頁應該有更多的細節。檢查你的OS文檔找出這個變量的最大值。試圖設定back_log高于你的操作系統的限制將是無效 的。
max_connections
并發連接數目最大，120 超過這個值就會自動恢復，出了問題能自動解決
thread_cache
沒找到具體說明，不過設置為32后 20天才創建了400多個線程 而以前一天就創建了上千個線程 所以還是有用的
thread_concurrency
#設置為你的cpu數目x2,例如，只有一個cpu,那么thread_concurrency=2
#有2個cpu,那么thread_concurrency=4
skip-innodb
#去掉innodb支持
代碼:
[client]
#password = your_password
port = 3306
socket = /tmp/mysql.sock
#socket = /var/lib/mysql/mysql.sock
# Here follows entries for some specific programs
# The MySQL server
[mysqld]
port = 3306
socket = /tmp/mysql.sock
#socket = /var/lib/mysql/mysql.sock
skip-locking
key_buffer = 128M
max_allowed_packet = 1M
table_cache = 256
sort_buffer_size = 1M
net_buffer_length = 16K
myisam_sort_buffer_size = 1M
max_connections=120
#addnew config
wait_timeout =120
back_log=100
read_buffer_size = 1M
thread_cache=32
skip-innodb
skip-bdb
skip-name-resolve
join_buffer_size=512k
query_cache_size = 32M
interactive_timeout=120
long_query_time=10
log_slow_queries= /usr/local/mysql4/logs/slow_query.log
query_cache_type= 1
# Try number of CPU's*2 for thread_concurrency
thread_concurrency = 4
[mysqldump]
quick
max_allowed_packet = 16M
[mysql]
no-auto-rehash
# Remove the next comment character if you are not familiar with SQL
#safe-updates
[isamchk]
key_buffer = 20M
sort_buffer_size = 20M
read_buffer = 2M
write_buffer = 2M
[myisamchk]
key_buffer = 20M
sort_buffer_size = 20M
read_buffer = 2M
write_buffer = 2M
[mysqlhotcopy]
interactive-timeout
補充
優 化table_cachetable_cache指定表高速緩存的大小。每當MySQL訪問一個表時，如果在表緩沖區中還有空間，該表就被打開并放入其 中，這樣可以更快地訪問表內容。通過檢查峰值時間的狀態值Open_tables和Opened_tables，可以決定是否需要增加 table_cache的值。如果你發現open_tables等于table_cache，并且opened_tables在不斷增長，那么你就需要增 加table_cache的值了（上述狀態值可以使用SHOW STATUS LIKE ‘Open%tables’獲得）。注意，不能盲目地把table_cache設置成很大的值。如果設置得太高，可能會造成文件描述符不足，從而造成性能 不穩定或者連接失敗。對于有1G內存的機器，推薦值是128－256。
案例1：該案例來自一個不是特別繁忙的服務器 table_cache – 512open_tables – 103 opened_tables – 1273 uptime – 4021421 (measured in seconds)該案例中table_cache似乎設置得太高了。在峰值時間，打開表的數目比table_cache要少得多。
案例 2：該案例來自一臺開發服務器。table_cache – 64open_tables – 64opened-tables – 431uptime – 1662790 (measured in seconds)雖然open_tables已經等于table_cache，但是相對于服務器運行時間來說，opened_tables的值也非常低。 因此，增加table_cache的值應該用處不大。
案例3：該案例來自一個upderperforming的服務器table_cache – 64 open_tables – 64 opened_tables – 22423uptime – 19538該案例中table_cache設置得太低了。雖然運行時間不到6小時，open_tables達到了最大值，opened_tables的值 也非常高。這樣就需要增加table_cache的值。優化key_buffer_sizekey_buffer_size指定索引緩沖區的大小，它決定 索引處理的速度，尤其是索引讀的速度。通過檢查狀態值Key_read_requests和Key_reads，可以知道key_buffer_size 設置是否合理。比例key_reads / key_read_requests應該盡可能的低，至少是1:100，1:1000更好（上述狀態值可以使用SHOW STATUS LIKE ‘key_read%’獲得）。key_buffer_size只對MyISAM表起作用。即使你不使用MyISAM表，但是內部的臨時磁盤表是 MyISAM表，也要使用該值。可以使用檢查狀態值created_tmp_disk_tables得知詳情。對于1G內存的機器，如果不使用 MyISAM表，推薦值是16M（8-64M）。
案例1：健康狀況key_buffer_size – 402649088 (384M) key_read_requests – 597579931 key_reads - 56188案例2：警報狀態key_buffer_size – 16777216 (16M)key_read_requests – 597579931key_reads - 53832731案例1中比例低于1:10000，是健康的情況；案例2中比例達到1:11，警報已經拉響。 ================================
Mysql調優中兩個重要參數table_cache和key_buffer
| 本文根據我自己的一點經驗，討論了Mysql服務器優化中兩個非常重要的參數，分別是table_cache，key_buffer_size。 ??table_cache 指示表高速緩存的大小。當Mysql訪問一個表時，如果在Mysql表緩沖區中還有空間，那么這個表就被打開并放入表緩沖區，這樣做的好處是可以更快速地 訪問表中的內容。一般來說，可以通過查看數據庫運行峰值時間的狀態值Open_tables和Opened_tables，用以判斷是否需要增加 table_cache的值，即如果open_tables接近table_cache的時候，并且Opened_tables這個值在逐步增加，那就要 考慮增加這個值的大小了。 ??在mysql默認安裝情況下，table_cache的值在2G內存以下的機器中的值默認時256到 512，如果機器有4G內存,則默認這個值是2048，但這決意味著機器內存越大，這個值應該越大，因為table_cache加大后，使得mysql對 SQL響應的速度更快了，不可避免的會產生更多的死鎖（dead lock），這樣反而使得數據庫整個一套操作慢了下來，嚴重影響性能。所以平時維護中還是要根據庫的實際情況去作出判斷，找到最適合你維護的庫的 table_cache值，有人說：“性能優化是一門藝術”，這話一點沒錯。大凡藝術品，大都是經過千錘百煉，精雕細琢而成。 ? ?這里還要說明一個問題，就是table_cache加大后碰到文件描述符不夠用的問題，在mysql的配置文件中有這么一段提示 引用 “The number of open tables for all threads. Increasing this value increases the number of file descriptors that mysqld requires. Therefore you have to make sure to set the amount of open files allowed to at least 4096 in the variable "open-files-limit" in” section [mysqld_safe]” 說 的就是要注意這個問題，一想到這里，部分兄弟可能會用ulimit -n 作出調整，但是這個調整實際是不對的，換個終端后，這個值又會回到原始值，所以最好用sysctl或者修改/etc/sysctl.conf文件，同時還 要在配置文件中把open_files_limit這個參數增大，對于4G內存服務器，相信現在購買的服務器都差不多用4G的了，那這個這個 open_files_limit至少要增大到4096，如果沒有什么特殊情況，設置成8192就可以了。 ? ?下面說說key_buffer_size這個參數，key_buffer_sizeO表示索引緩沖區的大小，嚴格說是它決定了數據庫索引處理的速度，尤 其是索引讀的速度。根據網絡一些高手寫的文章表示可以檢查狀態值Key_read_requests和Key_reads，即可知道 key_buffer_size設置是否合理。比例key_reads / key_read_requests應該盡可能的低，至少是1:100，1:1000更好，雖然我還沒有找到理論的依據，但是，我在自己維護的幾臺實際運 行良好的庫做過的測試后表明，這個比值接近1：20000，這從結果證明了他們說這話的正確性，我們不妨用之。 后記： ? ?我前面說過，性能優化是一件細活，影響mysql性能的因素很多，本文中只是選取了其中我認為比較重要的兩個參數，期待和網友一起探討更多mysql性能優化的技術。 |
轉載于:https://www.cnblogs.com/huangtaozi/p/3818357.html
總結
以上是生活随笔為你收集整理的Mysql数据库优化技术之配置篇、索引篇 （ 必看 必看 转）的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： AVAudioSession
- 下一篇： 遍历窗体中所有控件的信息