咱們就說下這個例子，提醒廣大開發在寫SQL的時候一定要仔細！
當時情況是這樣的，一個慢SQL把數據庫CPU連接數跑滿，由於併發壓力大，CPU空閒瞬時爲0，過一會機器被HANG死，連接不上。
因涉及公司隱私問題，我這裏用測試表代替，咱們主要看看是怎麼引起的。
表結構：
mysql> desc sbtest; +-------+------------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +-------+------------------+------+-----+---------+-------+ | id | int(11) | NO | PRI | 0 | | | k | int(10) unsigned | NO | MUL | 0 | | | c | char(120) | NO | | | | | pad | char(60) | NO | | | | +-------+------------------+------+-----+---------+-------+ 4 rows in set (0.22 sec)
現在開始了，開發寫了這麼一條SQL語句：
select * from sbtest where id in ('1','2','111111111111');（注：11個1）
各位，你們覺得這條SQL有問題嗎？很簡單，開發也認爲這麼簡單的SQL不用給DBA去審覈，但往往陰溝裏翻船，死在了自認爲簡單的SQL裏，那麼我們執行一下，看看執行計劃。
id是主鍵，卻沒有用到索引，全表掃描。這是爲毛？
溢出了。int最大寬度是11位，而我剛纔輸入了11個1，溢出了，如果換成10個1，再來看看效果。
已經用到索引，只需掃描3行就出結果。
下面再看看這兩條SQL的執行時間：
插入11個1，耗時4.39秒
插入10個1，耗時0.10秒
結論：
爲了避免這種問題的出現，int數值整形不要加''引號，如果是varchar字符串類型，要加上''引號。
血的教訓！請各位開發注意！數據庫是業務的核心，不能想當然，自己寫的痛快就直接跑現網，造成的損失是極大的。