MYSQL數(shù)據(jù)庫訪問性能優(yōu)化之常見誤區(qū)

       很多人為了統(tǒng)計記錄條數(shù)，就使用 count(1) 和count(primary_key) 而不是 count(*) ，他們認(rèn)為這樣性能更好，其實這是一個誤區(qū)。對于有些場景，這樣做可能性能會更差，應(yīng)為數(shù)據(jù)庫對 count(*) 計數(shù)操作做了一些特別的優(yōu)化。

2、count(column)和count(*)是一樣的

       這個誤區(qū)甚至在很多的資深工程師或者是 DBA 中都普遍存在，很多人都會認(rèn)為這是理所當(dāng)然的。實際上，count(column) 和 count(*) 是一個完全不一樣的操作，所代表的意義也完全不一樣。

       count(column) 是表示結(jié)果集中有多少個column字段不為空的記錄；

       count(*) 是表示整個結(jié)果集有多少條記錄。

3、select a,b from …比 select a,b,c from …可以讓數(shù)據(jù)庫訪問更少的數(shù)據(jù)量

       這個誤區(qū)主要存在于大量的開發(fā)人員中，主要原因是對數(shù)據(jù)庫的存儲原理不是太了解。

       實際上，大多數(shù)關(guān)系型數(shù)據(jù)庫都是按照行（row）的方式存儲，而數(shù)據(jù)存取操作都是以一個固定大小的IO單元（被稱作 block 或者 page）為單位，一般為4KB，8KB…大多數(shù)時候，每個IO單元中存儲了多行，每行都是存儲了該行的所有字段（lob等特殊類型字段除外）。

       所以，我們是取一個字段還是多個字段，實際上數(shù)據(jù)庫在表中需要訪問的數(shù)據(jù)量其實是一樣的。

       當(dāng)然，也有例外情況，那就是我們的這個查詢在索引中就可以完成，也就是說當(dāng)只取 a,b兩個字段的時候，不需要回表，而c這個字段不在使用的索引中，需要回表取得其數(shù)據(jù)。在這樣的情況下，二者的IO量會有較大差異。

4、order by一定需要排序操作

       索引數(shù)據(jù)實際上是有序的，如果我們的需要的數(shù)據(jù)和某個索引的順序一致，而且我們的查詢又通過這個索引來執(zhí)行，那么數(shù)據(jù)庫一般會省略排序操作，而直接將數(shù)據(jù)返回，因為數(shù)據(jù)庫知道數(shù)據(jù)已經(jīng)滿足我們的排序需求了。

       實際上，利用索引來優(yōu)化有排序需求的 SQL，是一個非常重要的優(yōu)化手段

5、執(zhí)行計劃中有 filesort 就會進(jìn)行磁盤文件排序

       有這個誤區(qū)其實并不能怪我們，而是因為 MySQL 開發(fā)者在用詞方面的問題。filesort是我們在使用 explain 命令查看一條 SQL 的執(zhí)行計劃的時候可能會看到在“Extra”一列顯示的信息。

       實際上，只要一條 SQL 語句需要進(jìn)行排序操作，都會顯示“Using filesort”，這并不表示就會有文件排序操作。

作者：黑馬程序員人工智能+Python培訓(xùn)學(xué)院

首發(fā)：http://python.itheima.com