mysql優(yōu)化方法(mysql優(yōu)化的常用方法)
1.mysql優(yōu)化的常用方法有哪些
1.對查詢進行優(yōu)化，應盡量避免全表掃描，首先應考慮在 where 及 order by 涉及的列上建立索引。
2.應盡量避免在 where 子句中使用！=或操作符，否則將引擎放棄使用索引而進行全表掃描。
3.應盡量避免在 where 子句中對字段進行 null 值判斷，否則將導致引擎放棄使用索引而進行全表掃描，如：
select id from t where num is null
可以在num上設置默認值0，確保表中num列沒有null值，然后這樣查詢：
select id from t where num=0
4.應盡量避免在 where 子句中使用 or 來連接條件，否則將導致引擎放棄使用索引而進行全表掃描，如：
select id from t where num=10 or num=20
可以這樣查詢：
select id from t where num=10
union all
select id from t where num=20
5.下面的查詢也將導致全表掃描：
select id from t where name like '%abc%'
若要提高效率，可以考慮全文檢索。
6.in 和 not in 也要慎用，否則會導致全表掃描，如：
select id from t where num in(1,2,3)
對于連續(xù)的數(shù)值，能用 between 就不要用 in 了：
select id from t where num between 1 and 3
7.如果在 where 子句中使用參數(shù)，也會導致全表掃描。因為SQL只有在運行時才會解析局部變量，但優(yōu)化程序不能將訪問計劃的選擇推遲到運行時；它必須在編譯時進行選擇。然而，如果在編譯時建立訪問計劃，變量的值還是未知的，因而無法作為索引選擇的輸入項。如下面語句將進行全表掃描：
select id from t where num=@num
可以改為強制查詢使用索引：
select id from t with(index（索引名）） where num=@num
8.應盡量避免在 where 子句中對字段進行表達式操作，這將導致引擎放棄使用索引而進行全表掃描。如：
select id from t where num/2=100
應改為：
select id from t where num=100*2
9.應盡量避免在where子句中對字段進行函數(shù)操作，這將導致引擎放棄使用索引而進行全表掃描。如：
select id from t where substring(name,1,3)='abc'--name以abc開頭的id
select id from t where datediff(day,createdate,'2005-11-30')=0--'2005-11-30'生成的id
應改為：
select id from t where name like 'abc%'
select id from t where createdate>='2005-11-30' and createdate
2.mysql的優(yōu)化方法
MySQL可以很好的支持大數(shù)據(jù)量的存取，但是一般說來，數(shù)據(jù)庫中的表越小，在它上面執(zhí)行的查詢也就會越快。因此，在創(chuàng)建表的時候，為了獲得更好的性能，我們可以將表中字段的寬度設得盡可能小。例如，在定義郵政編碼這個字段時，如果將其設置為CHAR(255)，顯然給數(shù)據(jù)庫增加了不必要的空間，甚至使用VARCHAR這種類型也是多余的，因為CHAR(6)就可以很好的完成任務了。同樣的，如果可以的話，我們應該使用MEDIUMINT而不是 BIGIN來定義整型字段。
另外一個提高效率的方法是在可能的情況下，應該盡量把字段設置為NOT NULL，這樣在將來執(zhí)行查詢的時候，數(shù)據(jù)庫不用去比較NULL值。
對于某些文本字段，例如“省份”或者“性別”，我們可以將它們定義為ENUM類型。因為在MySQL中，ENUM類型被當作數(shù)值型數(shù)據(jù)來處理，而數(shù)值型數(shù)據(jù)被處理起來的速度要比文本類型快得多。這樣，我們又可以提高數(shù)據(jù)庫的性能。
3.MySQL數(shù)據(jù)庫性能優(yōu)化有哪些技巧
1.存儲引擎的選擇如果數(shù)據(jù)表需要事務處理，應該考慮使用InnoDB，因為它完全符合ACID特性。如果不需要事務處理，使用默認存儲引擎MyISAM是比較明智的。并且不要嘗試同時使用這兩個存儲引擎。思考一下：在一個事務處理中，一些數(shù)據(jù)表使用InnoDB，而其余的使用MyISAM.結(jié)果呢？整個subject將被取消，只有那些在事務處理中的被帶回到原始狀態(tài)，其余的被提交的數(shù)據(jù)轉(zhuǎn)存，這將導致整個數(shù)據(jù)庫的沖突。然而存在一個簡單的方法可以同時利用兩個存儲引擎的優(yōu)勢。目前大多數(shù)MySQL套件中包括InnoDB、編譯器和鏈表，但如果你選擇MyISAM，你仍然可以單獨下載InnoDB，并把它作為一個插件。很簡單的方法，不是嗎？
2.計數(shù)問題如果數(shù)據(jù)表采用的存儲引擎支持事務處理（如InnoDB），你就不應使用COUNT（*)計算數(shù)據(jù)表中的行數(shù)。這是因為在產(chǎn)品類數(shù)據(jù)庫使用COUNT（*)，最多返回一個近似值，因為在某個特定時間，總有一些事務處理正在運行。如果使用COUNT（*)顯然會產(chǎn)生bug，出現(xiàn)這種錯誤結(jié)果。
3.反復測試查詢查詢最棘手的問題并不是無論怎樣小心總會出現(xiàn)錯誤，并導致bug出現(xiàn)。恰恰相反，問題是在大多數(shù)情況下bug出現(xiàn)時，應用程序或數(shù)據(jù)庫已經(jīng)上線。的確不存在針對該問題切實可行的解決方法，除非將測試樣本在應用程序或數(shù)據(jù)庫上運行。任何數(shù)據(jù)庫查詢只有經(jīng)過上千個記錄的大量樣本測試，才能被認可。
4.避免全表掃描通常情況下，如果MySQL（或者其他關系數(shù)據(jù)庫模型）需要在數(shù)據(jù)表中搜索或掃描任意特定記錄時，就會用到全表掃描。此外，通常最簡單的方法是使用索引表，以解決全表掃描引起的低效能問題。然而，正如我們在隨后的問題中看到的，這存在錯誤部分。
5.使用“EXPLAIN”進行查詢當需要調(diào)試時，EXPLAIN是一個很好的命令，下面將對EXPLAIN進行深入探討。
4.mysql 優(yōu)化包括哪些內(nèi)容
mysql的優(yōu)化大的有兩方面：1、配置優(yōu)化 配置的優(yōu)化其實包含兩個方面的：操作系統(tǒng)內(nèi)核的優(yōu)化和mysql配置文件的優(yōu)化 1）系統(tǒng)內(nèi)核的優(yōu)化對專用的mysql服務器來說，無非是內(nèi)存實用、連接數(shù)、超時處理、TCP處理等方面的優(yōu)化，根據(jù)自己的硬件配置來進行優(yōu)化，這里不多講； 2)mysql配置的優(yōu)化，一般來說包含：IO處理的常用參數(shù)、最大連接數(shù)設置、緩存使用參數(shù)的設置、慢日志的參數(shù)的設置、innodb相關參數(shù)的設置等，如果有主從關系在設置主從同步的相關參數(shù)即可，網(wǎng)上的相關配置文件很多，大同小異，常用的設置大多修改這些差不多就夠用了。
2、sql語句的優(yōu)化1、盡量稍作計算 Mysql的作用是用來存取數(shù)據(jù)的，不是做計算的，做計算的話可以用其他方法去實現(xiàn)，mysql做計算是很耗資源的。2.盡量少 join MySQL 的優(yōu)勢在于簡單，但這在某些方面其實也是其劣勢。
MySQL 優(yōu)化器效率高，但是由于其統(tǒng)計信息的量有限，優(yōu)化器工作過程出現(xiàn)偏差的可能性也就更多。對于復雜的多表 Join，一方面由于其優(yōu)化器受限，再者在 Join 這方面所下的功夫還不夠，所以性能表現(xiàn)離 Oracle 等關系型數(shù)據(jù)庫前輩還是有一定距離。
但如果是簡單的單表查詢，這一差距就會極小甚至在有些場景下要優(yōu)于這些數(shù)據(jù)庫前輩。3.盡量少排序 排序操作會消耗較多的 CPU 資源，所以減少排序可以在緩存命中率高等 IO 能力足夠的場景下會較大影響 SQL的響應時間。
對于MySQL來說，減少排序有多種辦法，比如： 通過利用索引來排序的方式進行優(yōu)化 減少參與排序的記錄條數(shù) 非必要不對數(shù)據(jù)進行排序4.盡量避免 select * 在數(shù)據(jù)量少并且訪問量不大的情況下，select * 沒有什么影響，但是量級達到一定級別的時候，在執(zhí)行效率和IO資源的使用上，還是有很大關系的，用什么字段取什么字段，減少不必要的資源浪費。 之前遇到過因為一個字段存儲的數(shù)據(jù)比較大，并發(fā)高的情況下把網(wǎng)絡帶寬跑滿的情況，造成網(wǎng)站打不開或是打開速度極慢的情況。
5.盡量用 join 代替子查詢 雖然 Join 性能并不佳，但是和 MySQL 的子查詢比起來還是有非常大的性能優(yōu)勢。MySQL 的子查詢執(zhí)行計劃一直存在較大的問題，雖然這個問題已經(jīng)存在多年，但是到目前已經(jīng)發(fā)布的所有穩(wěn)定版本中都普遍存在，一直沒有太大改善。
雖然官方也在很早就承認這一問題，并且承諾盡快解決，但是至少到目前為止我們還沒有看到哪一個版本較好的解決了這一問題。6.盡量少 or 當 where 子句中存在多個條件以“或”并存的時候，MySQL 的優(yōu)化器并沒有很好的解決其執(zhí)行計劃優(yōu)化問題，再加上 MySQL 特有的 SQL 與 Storage 分層架構(gòu)方式，造成了其性能比較低下，很多時候使用 union all 或者是union（必要的時候）的方式來代替“or”會得到更好的效果。
7.盡量用 union all 代替 union union 和 union all 的差異主要是前者需要將兩個（或者多個）結(jié)果集合并后再進行唯一性過濾操作，這就會涉及到排序，增加大量的 CPU 運算，加大資源消耗及延遲。所以當我們可以確認不可能出現(xiàn)重復結(jié)果集或者不在乎重復結(jié)果集的時候，盡量使用 union all 而不是 union。
8.盡量早過濾 這一優(yōu)化策略其實最常見于索引的優(yōu)化設計中（將過濾性更好的字段放得更靠前）。 在 SQL 編寫中同樣可以使用這一原則來優(yōu)化一些 Join 的 SQL。
比如我們在多個表進行分頁數(shù)據(jù)查詢的時候，我們最好是能夠在一個表上先過濾好數(shù)據(jù)分好頁，然后再用分好頁的結(jié)果集與另外的表 Join，這樣可以盡可能多的減少不必要的 IO 操作，大大節(jié)省 IO 操作所消耗的時間。9.避免類型轉(zhuǎn)換 這里所說的“類型轉(zhuǎn)換”是指 where 子句中出現(xiàn) column 字段的類型和傳入的參數(shù)類型不一致的時候發(fā)生的類型轉(zhuǎn)換：A：人為在column_name 上通過轉(zhuǎn)換函數(shù)進行轉(zhuǎn)換 直接導致 MySQL（實際上其他數(shù)據(jù)庫也會有同樣的問題）無法使用索引，如果非要轉(zhuǎn)換，應該在傳入的參數(shù)上進行轉(zhuǎn)換 B：由數(shù)據(jù)庫自己進行轉(zhuǎn)換 如果我們傳入的數(shù)據(jù)類型和字段類型不一致，同時我們又沒有做任何類型轉(zhuǎn)換處理，MySQL 可能會自己對我們的數(shù)據(jù)進行類型轉(zhuǎn)換操作，也可能不進行處理而交由存儲引擎去處理，這樣一來，就會出現(xiàn)索引無法使用的情況而造成執(zhí)行計劃問題。
以上兩種情況在開發(fā)者因為某種原因經(jīng)常會有，本來可以用到索引的結(jié)果類型不對沒有用到索引，或是因為類型不對又有越界的情況發(fā)生造成無法使用索引的情況，結(jié)果造成很嚴重的事故。10.優(yōu)先優(yōu)化高并發(fā)的 SQL，而不是執(zhí)行頻率低某些“大”SQL 對于破壞性來說，高并發(fā)的 SQL 總是會比低頻率的來得大，因為高并發(fā)的 SQL 一旦出現(xiàn)問題，甚至不會給我們?nèi)魏未⒌臋C會就會將系統(tǒng)壓跨。
而對于一些雖然需要消耗大量 IO 而且響應很慢的 SQL，由于頻率低，即使遇到，最多就是讓整個系統(tǒng)響應慢一點，但至少可能撐一會兒，讓我們有緩沖的機會。11.從全局出發(fā)優(yōu)化，而不是片面調(diào)整 SQL 優(yōu)化不能是單獨針對某一個進行，而應充分考慮系統(tǒng)中所有的 SQL，尤其是在通過調(diào)整索引優(yōu)化 SQL 的執(zhí)行計劃的時候，千萬不能顧此失彼，因小失大。
12.盡可能對每一條運行在數(shù)據(jù)庫中的SQL進行 explain 優(yōu)化 SQL，需要做到心中有數(shù)，知道。
5.講述mysql數(shù)據(jù)表幾種有效優(yōu)化方法
下面我們要四種關于mysql教程數(shù)據(jù)表幾種有效優(yōu)化方法
哦，從而提高mysql數(shù)據(jù)庫教程在應用方面的數(shù)據(jù)吞吐能力。
一、優(yōu)化表的數(shù)據(jù)類型
select * from tablename procedure analyse();
select * from tablename procedure analyse(16.265);
上面輸出一列信息，牟你數(shù)據(jù)表的字段提出優(yōu)化建義，
二、通過拆分表提高數(shù)據(jù)訪問效率
拆分一是指針對表進行拆分，如果是針對myisam類型的表進行處理的話，可以有兩種拆分方法
1、是垂直拆分，把主要的與一些散放到一個表，然后把主要的和另外的列放在另一張表。
2、水平拆分方法，根據(jù)一列或多列的值把數(shù)據(jù)行放到兩個獨立的表中，水平拆分通常幾種情況。
表很大，拆分后可降低查詢時數(shù)據(jù)和索引的查詢速度，同時也降低了索引的層數(shù)，提高查詢的速度。
表中的數(shù)據(jù)本來就有獨立性，表中分別記錄各個地區(qū)的數(shù)據(jù)或不同時期的數(shù)據(jù)，特別是有些數(shù)據(jù)常用，廁國一些數(shù)據(jù)不常用的情況下，
需要把數(shù)據(jù)存放到多個不同的介質(zhì)上。
三、逆規(guī)范化
四、使用中間表優(yōu)化方法對于數(shù)據(jù)庫教程大的表，在進行統(tǒng)計查詢時通常會比較慢的，并且還要考慮查詢是否會對在線應用產(chǎn)生影響，通常這種情況下我們使用中間表可以提高查詢統(tǒng)計速度
6.優(yōu)化MYSQL數(shù)據(jù)庫的方法
(1).選取最適用的字段屬性，應該盡量把字段設置為NOT NULL，這樣在將來執(zhí)行查詢的時候，數(shù)據(jù)庫不用去比較NULL值。
(2).使用連接（JOIN）來代替子查詢（Sub-Queries）
(3).使用聯(lián)合（UNION）來代替手動創(chuàng)建的臨時表
(4).盡量少使用 LIKE 關鍵字和通配符
(5).使用事務和外鍵
或者
(1).數(shù)據(jù)庫設計方面，這是DBA和Architect的責任，設計結(jié)構(gòu)良好的數(shù)據(jù)庫，必要的時候，去正規(guī)化（英文是這個：denormalize，中文翻譯成啥我不知道），允許部分數(shù)據(jù)冗余，避免JOIN操作，以提高查詢效率
(2).系統(tǒng)架構(gòu)設計方面，表散列，把海量數(shù)據(jù)散列到幾個不同的表里面.快慢表，快表只留最新數(shù)據(jù)，慢表是歷史存檔.集群，主服務器Read & write，從服務器read only，或者N臺服務器，各機器互為Master
(3).(1)和（2）超越PHP Programmer的要求了，會更好，不會沒關系.檢查有沒有少加索引
(4).寫高效的SQL語句，看看有沒有寫低效的SQL語句，比如生成笛卡爾積的全連接啊，大量的Group By和order by，沒有l(wèi)imit等等.必要的時候，把數(shù)據(jù)庫邏輯封裝到DBMS端的存儲過程里面.緩存查詢結(jié)果，explain每一個sql語句
(5).所得皆必須，只從數(shù)據(jù)庫取必需的數(shù)據(jù)，比如查詢某篇文章的評論數(shù)，select count(*) 。 where article_id = 就可以了，不要先select * 。 where article_id = 然后msql_num_rows.只傳送必須的SQL語句，比如修改文章的時候，如果用戶只修改了標題，那就update 。 set title = where article_id = 不要set content = （大文本）
(6).必要的時候用不同的存儲引擎.比如InnoDB可以減少死鎖.HEAP可以提高一個數(shù)量級的查詢速度
7.優(yōu)化MYSQL數(shù)據(jù)庫常用的方法
1） 數(shù)據(jù)庫設計方面設計結(jié)構(gòu)良好的數(shù)據(jù)庫，必要的時候，去正規(guī)化允許部分數(shù)據(jù)冗余，避免 JOIN 操作，以提高查詢效率2） 系統(tǒng)架構(gòu)設計方面，表散列，把海量數(shù)據(jù)散列到幾個不同的表里面。
快慢表，快表只留最新數(shù)據(jù)，慢表是歷史存檔。集群，主服務器進行讀寫，從服務器只讀，或者 N 臺服務器，各機器互為 Master3） 檢查有沒有少加索引4） 寫高效的 SQL 語句，減少低效的 SQL 語句，比如生成笛卡爾積的全連接，大量的 Group By 和 order by,limit 等等。
必要的時候，把數(shù)據(jù)庫邏輯封裝到 DBMS 端的存儲過程里面。緩存查詢結(jié)果，explain 每一個 sql語句5） 必要的時候用不同的存儲引擎。
比如 InnoDB 可以減少死鎖， HEAP 可以提高一個數(shù)量級的查詢速度。
8.mysql數(shù)據(jù)庫表太大查詢慢優(yōu)化的幾種方法
優(yōu)化方案：
主從同步+讀寫分離：
這個表在有設備條件的情況下，讀寫分離，這樣能減少很多壓力，而且數(shù)據(jù)穩(wěn)定性也能提高
縱向分表：
根據(jù)原則，每個表最多不要超過5個索引，縱向拆分字段，將部分字段拆到一個新表
通常我們按以下原則進行垂直拆分：（先區(qū)分這個表中的冷熱數(shù)據(jù)字段）
把不常用的字段單獨放在一張表；
把text,blob等大字段拆分出來放在附表中；
經(jīng)常組合查詢的列放在一張表中；
缺點是：很多邏輯需要重寫，帶來很大的工作量。
利用表分區(qū)：
這個是推薦的一個解決方案，不會帶來重寫邏輯等，可以根據(jù)時間來進行表分區(qū)，相當于在同一個磁盤上，表的數(shù)據(jù)存在不同的文件夾內(nèi)，能夠極大的提高查詢速度。
橫向分表：
1000W條數(shù)據(jù)不少的，會帶來一些運維壓力，備份的時候，單表備份所需時間會很長，所以可以根據(jù)服務器硬件條件進行水平分表，每個表有多少數(shù)據(jù)為準。
9.優(yōu)化MySQL數(shù)據(jù)庫的方法有哪些呢
#1： 使用索引 MySQL允許對數(shù)據(jù)庫表進行索引，以此能迅速查找記錄，而無需一開始就掃描整個表，由此顯著地加快查詢速度。
每個表最多可以做到16個索引，此外MySQL還支持多列索引及全文檢索。 給表添加一個索引非常簡單，只需調(diào)用一個CREATE INDEX命令并為索引指定它的域即可。
列表A給出了一個例子：列表 Amysql> CREATE INDEX idx_username ON users(username);Query OK, 1 row affected (0。15 sec)Records: 1 Duplicates: 0 Warnings: 0 這里，對users表的username域做索引，以確保在WHERE或者HAVING子句中引用這一域的SELECT查詢語句運行速度比沒有添加索引時要快。
通過SHOW INDEX命令可以查看索引已被創(chuàng)建（列表B）。列表 Bmysql> SHOW INDEX FROM users;--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment |--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+| users | 1 | idx_username | 1 | username | A | NULL | NULL | NULL | YES | BTREE | |--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+1 row in set (0。
00 sec) 值得注意的是：索引就像一把雙刃劍。對表的每一域做索引通常沒有必要，且很可能導致運行速度減慢，因為向表中插入或修改數(shù)據(jù)時，MySQL不得不每次都為這些額外的工作重新建立索引。
另一方面，避免對表的每一域做索引同樣不是一個非常好的主意，因為在提高插入記錄的速度時，導致查詢操作的速度減慢。 這就需要找到一個平衡點，比如在設計索引系統(tǒng)時，考慮表的主要功能（數(shù)據(jù)修復及編輯）不失為一種明智的選擇。
#2： 優(yōu)化查詢性能 在分析查詢性能時，考慮EXPLAIN關鍵字同樣很管用。EXPLAIN關鍵字一般放在SELECT查詢語句的前面，用于描述MySQL如何執(zhí)行查詢操作、以及MySQL成功返回結(jié)果集需要執(zhí)行的行數(shù)。
下面的一個簡單例子可以說明（列表C）這一過程：列表 Cmysql> EXPLAIN SELECT city。name, city。
district FROM city, country WHERE city。countrycode = country。
code AND country。code = 'IND';+----+-------------+---------+-------+---------------+---------+---------+-------+------+-------------+| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |+----+-------------+---------+-------+---------------+---------+---------+-------+------+-------------+| 1 | SIMPLE | country | const | PRIMARY | PRIMARY | 3 | const | 1 | Using index || 1 | SIMPLE | city | ALL | NULL | NULL | NULL | NULL | 4079 | Using where |+----+-------------+---------+-------+---------------+---------+---------+-------+------+-------------+2 rows in set (0。
00 sec)這里查詢是基于兩個表連接。EXPLAIN關鍵字描述了MySQL是如何處理連接這兩個表。
必須清楚的是，當前設計要求MySQL處理的是country表中的一條記錄以及city表中的整個4019條記錄。這就意味著，還可使用其他的優(yōu)化技巧改進其查詢方法。
例如，給city表添加如下索引（列表D）：列表 Dmysql> CREATE INDEX idx_ccode ON city(countrycode);Query OK, 4079 rows affected (0。15 sec)Records: 4079 Duplicates: 0 Warnings: 0現(xiàn)在，當我們重新使用EXPLAIN關鍵字進行查詢時，我們可以看到一個顯著的改進（列表E）：列表 Emysql> EXPLAIN SELECT city。
name, city。district FROM city, country WHERE city。
countrycode = country。code AND country。
code = 'IND';+----+-------------+---------+-------+---------------+-----------+---------+-------+------+-------------+| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |+----+-------------+---------+-------+---------------+-----------+---------+-------+------+-------------+| 1 | SIMPLE | country | const | PRIMARY | PRIMARY | 3 | const | 1 | Using index || 1 | SIMPLE | city | ref | idx_ccode | idx_ccode | 3 | const | 333 | Using where |+----+-------------+---------+-------+---------------+-----------+---------+-------+------+-------------+2 rows in set (0。 01 sec) 在這個例子中，MySQL現(xiàn)在只需要掃描city表中的333條記錄就可產(chǎn)生一個結(jié)果集，其掃描記錄數(shù)幾乎減少了90%！自然，數(shù)據(jù)庫資源的查詢速度更快，效率更高。
#3： 調(diào)整內(nèi)部變量 MySQL是如此的開放，所以可輕松地進一步調(diào)整其缺省設置以獲得更優(yōu)的性能及穩(wěn)定性。 需要優(yōu)化的一些關鍵變量如下：改變索引緩沖區(qū)長度（key_buffer） 一般，該變量控制緩沖區(qū)的長度在處理索引表（讀/寫操作）時使用。
MySQL使用手冊指出該變量可以不斷增加以確保索引表的最佳性能，并推薦使用與系統(tǒng)內(nèi)存25%的大小作為該變量的值。 這是MySQL十分重要的配置變量之一，如果你對優(yōu)化和提高系統(tǒng)性能有興趣，可以從改變key_buffer_size變量的值開始。
改變表長（read_buffer_size） 當一個查詢不斷地掃描某一個表，MySQL會為它分配一段內(nèi)存緩沖區(qū)。read_buffer_size變量控制這一緩沖區(qū)的大小。
如果你認為連續(xù)掃描進行得太慢，可以。
