設置MySQL中的數據類型來優化運轉速度的實例

設置MySQL中的數據類型來優化運轉速度的實例。本站提示廣大學習愛好者：（設置MySQL中的數據類型來優化運轉速度的實例）文章只能為提供參考，不一定能成為您想要的結果。以下是設置MySQL中的數據類型來優化運轉速度的實例正文

明天看了一個優化案例覺的挺有代表性,這裡記載上去做一個標志，來留念一下隨意的字段界說的成績。

回想一下,在表的設計中許多人習氣的把表的構造設計成Varchar(64),Varchar(255)之類的,固然年夜多半情形只存了5-15個字節.那末我看一下上面這個案例.
查詢語句:
 

 SELECT SQL_NO_CACHE channel, COUNT(channel) AS visitors FROM xxx_sources WHERE client_id = 1301 GROUP BY client_id, channel;

該表(client_id,channel)是一個組合索引.
應用explain,看一下履行籌劃,關於索引應用上看上異常完善
 

mysql> explain SELECT SQL_NO_CACHE channel, COUNT(channel) AS visitors FROM xxx_sources WHERE client_id = 1301 GROUP BY client_id, channel;
+----+-------------+-------------+-------+--------------------+--------------------+---------+------+----------+--------------------------+
| id | select_type | table  | type | possible_keys  | key    | key_len | ref | rows  | Extra     |
+----+-------------+-------------+-------+--------------------+--------------------+---------+------+----------+--------------------------+
| 1 | SIMPLE  | xxx_sources | index | idx_client_channel | idx_client_channel | 1032 | NULL | 20207319 | Using where; Using index |
+----+-------------+-------------+-------+--------------------+--------------------+---------+------+----------+--------------------------+
1 row in set (0.00 sec)

看一下現實履行:
 

mysql> SELECT SQL_NO_CACHE channel, COUNT(channel) AS visitors FROM xxx_sources WHERE client_id = 1301 GROUP BY client_id, channel;
+---------+----------+
| channel | visitors |
+---------+----------+
| NULL |  0 |
+---------+----------+
1 row in set (11.69 sec)

現實履行的情形異常的蹩腳.傳通的設法主意,這個履行從索引上履行籌劃上看異常完善了,好象和MySQL沒甚麼關系了. 在去看一下表的設計會發明client_id也是設計成了
varchar(255).看到這裡不防可使用上面的辦法試一下:

mysql> explain SELECT SQL_NO_CACHE channel, COUNT(channel) AS visitors FROM xxx_sources WHERE client_id = '1301' GROUP BY client_id, channel;
+----+-------------+-------------+------+--------------------+--------------------+---------+-------+--------+--------------------------+
| id | select_type | table  | type | possible_keys  | key    | key_len | ref | rows | Extra     |
+----+-------------+-------------+------+--------------------+--------------------+---------+-------+--------+--------------------------+
| 1 | SIMPLE  | xxx_sources | ref | idx_client_channel | idx_client_channel | 258  | const | 457184 | Using where; Using index |
+----+-------------+-------------+------+--------------------+--------------------+---------+-------+--------+--------------------------+
1 row in set (0.00 sec)

從履行籌劃下去看,差不多,但現實差多了.詳細下去看key_len從1032降到了258,履行籌劃釀成了const基於等於的查找,行數從本來萬萬級到了十萬級了.不算也能明確IO
節儉了許多.
再來看現實履行:

mysql> SELECT SQL_NO_CACHE channel, COUNT(channel) AS visitors FROM xxx_sources WHERE client_id = '1301' GROUP BY client_id, channel;
+---------+----------+
| channel | visitors |
+---------+----------+
| NULL |  0 |
+---------+----------+
1 row in set (0.25 sec)

哇,從11.69秒釀成了0.25秒,這是甚麼概念,優化了若干倍,算一下吧.

看到這裡在想甚麼呢,記住這個案例,嗯,不錯,今後還可以加引號優化一下.那為何不問一下,能不克不及在優化了,為何會如許呢?
我們先來看一下第一個成績：
能不克不及在優化了?
謎底是固然可以了.從索引的長度下去看258照樣一個異常年夜的數據,關於client_id這個字段從名字下去看,也只會存數據型的值,那為何不消的一個int unsigned去存呢,
索引的長度立時會從258降到4。如許不是又節儉了許多嗎？
接上去看一下第二個成績，為何會如許呢？
緣由有兩點，同時基於一個准繩，基於本錢的優化器。關於client_id在表的界說時界說成了字符型的值，在查詢時傳入了數值型的值，須要經由一個數值轉換，喜劇的開端，終究
招致MySQL選擇了一個完成的索引去掃描。

從這個案例上，我們須要留意甚麼呢？
公道的選擇數據類型，根本工太主要了，就這叫贏在起跑線，一切都不克不及隨意了，別把一個表界說成了降了主建外其它滿是Varchar(255)。對數據庫的double/float這類字段做索引時必定要當心。