摘要：現在的排序是根據數據表中的主鍵序號進行的排序，沒有達到想要的效果。

答：

在日常的業務開發中，常見使用到索引的地方大概有兩類：
（1）做業務約束需求，比如需要保證表中每行的單個字段或者某幾個組合字段是唯一的，則可以在表中創建唯一索引
（2）提高SQL語句執行速度，可以根據SQL語句的查詢條件在表中創建合適的索引，以此來提升SQL語句的執行速度

1、在圖書數據庫數據表的書名字段里，按圖書書名進行關鍵字搜索，如何快速搜索相關的圖書？ 現在由于數據不多，直接用的like模糊查找驗證功能而已；
2、如何按匹配的關鍵度進行快速排序？比如搜索“算法”，有一本書是《算法》，另一本書是《算法設計》，要求前者排在更前面。現在的排序是根據數據表中的主鍵序號id進行的排序，沒有達到想要的效果。

答：

1、如果數據量不大，是可以在數據庫中完成搜索的，可以在搜索字段上創建索引，然后進行搜索查詢：
CREATE TABLE `book` (  
  `book_id` int(11) NOT NULL AUTO_INCREMENT,  
  `book_name` varchar(100) NOT NULL,  
  .............................  
  PRIMARY KEY (`book_id`),  
  KEY `ind_name` (`book_name`)  
) ENGINE=InnoDB  
select book.*  from book , (select book_id from book where book_name like "%算法%")  book_search_id  where book.book_id=book_search_id.book_id;
但是當數據量變得很大后，就不在適合了，可以采用一些其他的第三方搜索技術比如sphinx。

2、select book_id,book_name from book_search where book_name like "%算%" order by book_name;  
+---------+--------------+  
| book_id | book_name    |  
+---------+--------------+  
|       2 | 算法       |  
|       1 | 算法設計 | 

答：

模糊查詢分為半模糊和全模糊，也就是：

select * from book where name like "xxx%";(半模糊)  
select * from book where name like "%xxx%";(全模糊)  

半模糊可以可以使用到索引，全模糊在上面場景是不能使用到索引的，但可以進行一些改進，比如：

select book.*  from book , (select book_id from book where book_name like "%算法%")  book_search_id where book.book_id=book_search_id.book_id;   

注意這里book_id是主鍵，同時在book_name上創建了索引
上面的sql語句可以利用全索引掃描來完成優化，但是性能不會太好；特別在數據量大，請求頻繁的業務場景下不要在數據庫進行模糊查詢；非得使用數據庫的話 ，建議不要在生產庫進行查詢，可以在只讀節點進行查詢，避免查詢造成主業務數據庫的資源消耗完，導致故障. 可以使用一些開源的搜索引擎技術，比如sphinx.

答：

SQL優化需要了解優化器原理，索引的原理，表的存儲結構，執行計劃等，可以買一本書來系統的進行學習，多多實驗；不同的數據庫優化器的模型不一樣，比如oracle支持NL，HJ，SMJ，但是mysql只支持NL，不通的連接方式適用于不同的應用場景；
NL：對于被連接的數據子集較小的情況，嵌套循環連接是個較好的選擇
HJ：對于列連接是做大數據集連接時的常用方式
SMJ：通常情況下散列連接的效果都比排序合并連接要好，然而如果行源已經被排過序，在執行排序合并連接時不需要再排序了，這時排序合并連接的性能會優于散列連接。

CREATE TABLE TQueCategory  
(  
ID INT IDENTITY(1,1) PRIMARY KEY,        --問題分類ID  
NAME VARCHAR(20)        --問題分類名稱  
)  
CREATE TABLE TQuestion  
(  
ID INT IDENTITY(1,1) PRIMARY KEY,        --問題ID  
CateID INT NOT NULL,        --問題分類ID  
TITLE VARCHAR(50),        --問題標題  
CONTENT VARCHAR(500)        --問題內容  
)  

當前要統計某個分類下的問題數，有兩種方式：
1.每次統計，在TQuestion通過CateID進行分組統計
SELECT CateID,COUNT(1) AS QueNum FROM TQuestion GROUP BY CateID WHERE 1=1
2.在TQueCategory表增加字段QueNum，用于標識該分類下的問題數量
ALTER TABLE TQueCategory ADD QueNum INT
SELECT CateID,QueNum FROM TQueCategory
問：在哪種業務應用場景下采用上面哪種方式性能比較好，為什么？

答：

方案 一 需要對 TQuestion 的 CateID字段 進行分組 ，可以在CateID上創建一個索引，這樣就可以索引掃描來完成查詢；
方案 二 需要對 TQueCategory 進行掃描就可以得出結果，但是必須在問題表有插入，刪除的時候維護quenum數量；
分析：
單單從SQL的性能來看，分類表的數量應該是遠遠小于問題表的數量的，所以方案二的性能會比較好； 但是如果TQuestion 的插入非常頻繁的話，會帶來對TQueCategory的頻繁更新，一次TQuestion 的insert或deleted就會帶來一次TQueCategory 的update，這個代價其實是蠻高的； 如果這個分類統計的查詢不是非常頻繁的話，建議還是使用方案一； 同時還可能還會其他的業務邏輯統計需求（例如：CateID +時間），這個時候在把邏輯放到TQueCategory就不合適了。

答：

普通寫法：
select * from t where sellerid=100 limit 100000，20
普通limit M，N的翻頁寫法，往往在越往后翻頁的過程中速度越慢，原因
mysql會讀取表中的前M+N條數據，M越大，性能就越差。

優化寫法：

select t1.* from  t t1,(select id from t where sellerid=100 limit 100000，20) t2 where t1.id=t2.id;  

優化后的翻頁寫法，先查詢翻頁中需要的N條數據的主鍵id，在根據主鍵id回表查詢所需要的N條數據，此過程中查詢N條數據的主鍵ID在索引中完成
注意：需要在t表的sellerid字段上創建索引

create index ind_sellerid on t(sellerid);

案例：
慢查詢：

select id, ... from t_buyer where sellerId = 765922982 and  
gmt_modified >= "1970-01-01 08:00:00" and gmt_modified <= "2013-06-05 17:11:31"   
limit 255000, 5000;
5000 rows in set (90 sec)

優化后：

selectt2.* from 
(select id from t_buyer where sellerId = 765922982 and
andgmt_modified >= "1970-01-01 08:00:00" and
andgmt_modified <= "2013-06-05 17:11:31"   
limit 255000, 5000）t1,t_buyer t2 where t1.id=t2.id  
index：seller_id,gmt_modified
5000 rows in set (4.25 sec)

答：

這里的不建議使用外鍵，主要考慮到 ：
第一.維護成本上，把一些業務邏輯交由數據庫來保證，當業務需求發生改動的時候，需要同時考慮應用程序和數據庫，有時候一些數據庫變更或者bug，可能會導致外鍵的失效；同時也給數據庫的管理人員帶來維護的麻煩，不便于管理。
第二.性能上考慮，當大量數據寫入的時候，外鍵肯定會帶來一定的性能損耗，當出現這樣的問題時候，再來改造去除外鍵，真的就不值得了；
最后，不在數據庫中參與業務的計算（存儲過程，函數，觸發器，外鍵），是保證數據庫運行穩定的一個好的最佳實踐。

答：

1.可以將mysql的慢日志打開，就可以記錄執行時間超過指定閥值的慢SQL到本地文件或者數據庫的slow_log表中;在RDS中默認是打開了慢日志功能的：long_query_time=1，表示會記錄執行時間>=1秒的慢sql;

2.如何快速找到mysql瓶頸:
簡單一點的方法，可以通過監控mysql所在主機的性能（CPU，IO，load等）,以及mysql本身的一些狀態值（connections，thread running，qps，命中率等;
RDS提供了完善的數據庫監控體系，包括了CPU，IOPS，Disk，Connections，QPS，可以重點關注cpu，IO，connections，disk 4個 指標; cpu，io，connections主要體現在了性能瓶頸，disk主要體現了空間瓶頸；
有時候一條慢sql語句的頻繁調用，也可能導致整個實例的cpu，io，connections達到100%;也有可能一條排序的sql語句，消耗大量的臨時空間，導致實例的空間消耗完。