原文地址：http://mp.weixin.qq.com/s?__biz=MjM5MjIxNDA4NA==&mid=401131835&idx=1&sn=37c5fd9d3d8670fb379a1e0565e50eeb&scene=0#wechat_redirect
創(chuàng)建索引是門技術(shù)活，開發(fā)DBA的工作之一就是配合應(yīng)用創(chuàng)建最優(yōu)的索引。然大部分公司并沒有開發(fā)DBA一職，大多數(shù)的索引創(chuàng)建需要由程序開發(fā)人員自己完成，這導(dǎo)致的一個后果是，索引創(chuàng)建的好與壞大部分情況下需要看這個程序猿的氣質(zhì)。
千山網(wǎng)站建設(shè)公司創(chuàng)新互聯(lián),千山網(wǎng)站設(shè)計制作，有大型網(wǎng)站制作公司豐富經(jīng)驗。已為千山成百上千家提供企業(yè)網(wǎng)站建設(shè)服務(wù)。企業(yè)網(wǎng)站搭建\外貿(mào)網(wǎng)站制作要多少錢，請找那個售后服務(wù)好的千山做網(wǎng)站的公司定做！
通常，Inside君通過下面這條SQL語句來檢視創(chuàng)建的索引（同時喝著咖啡，聽著音樂），大部分情況下可以定位出90%的索引創(chuàng)建不合理情況：
可惜的是上述SQL語句并不能工作在MySQL 5.6版本下（即使最新的MySQL 5.6.28版本），因為目前5.6的STATISTICS表中關(guān)于Cardinality的統(tǒng)計是錯誤的?。?！具體可見
MySQL bugs #78066。但是，表innodb_index_stats中關(guān)于Cardinality值得統(tǒng)計依然是正確的，那么問題來了：
-
有誰知道5.6下上述SQL該如何改寫？
-
如何修復(fù)5.6下的Cardinality Bug？
版本《=5.6
-
查找未被使用的索引：
-
mysql> select OBJECT_SCHEMA,OBJECT_NAME,INDEX_NAME from performance_schema.table_io_waits_summary_by_index_usage where INDEX_NAME is not null and COUNT_STAR=0 and OBJECT_SCHEMA='xdq' and OBJECT_NAME='order_reasons_dispute' order by OBJECT_SCHEMA,OBJECT_NAME;
+---------------+-----------------------+------------+
| OBJECT_SCHEMA | OBJECT_NAME | INDEX_NAME |
+---------------+-----------------------+------------+
| xdq | order_reasons_dispute | PRIMARY |
| xdq | order_reasons_dispute | s_uid |
| xdq | order_reasons_dispute | b_uid |
| xdq | order_reasons_dispute | c_time |
| xdq | order_reasons_dispute | r_time |
+---------------+-----------------------+------------+
5 rows in set (0.15 sec)
版本=5.7
-
mysql> select * from sys.schema_redundant_indexes 冗余索引
-
mysql> select * from schema_unused_indexes ; 未使用索引 --詳見mysql5.7 sys schema視圖詳解
-
mysql> select * from statements_with_full_table_scans; 使用全表掃描的sql語句 等
文章標(biāo)題：【Mysql】快速定位不合理的索引——MySQL索引調(diào)優(yōu)（一）
文章路徑：
http://weahome.cn/article/ghhojg.html
重慶分公司
重慶分公司
