mysql遇到的問題

按照漢字的拼音排序

查出的人名須要按照漢字的拼音排序，從A到Z。

若是存儲姓名的字段採用的是GBK字符集，那就好辦了，由於GBK內碼編碼時自己就採用了拼音排序的方法（經常使用一級漢字3755個採用拼音排序，二級漢字就不是了，但考慮到人名等都是經常使用漢字，所以只是針對一級漢字能正確排序也夠用了）。
直接在查詢語句後面 添加 order by name asc; 查詢結果按照姓氏的升序排序；
若是存儲姓名的字段採用的是 utf8字符集，須要在排序的時候對字段進行轉碼；對於的代碼是 order by convert(name using gbk) asc; 一樣，查詢的結果也是按照姓氏的升序排序；

對於包含中文的字段加上」binary」屬性，使之做爲二進制比較，例如將」name char(10)」改爲」name char(10)binary」。
若是你使用源碼編譯MySQL，能夠編譯MySQL時使用 –with–charset=gbk 參數，這樣MySQL就會直接支持中文查找和排序了（默認的是latin1）。也能夠用 extra-charsets=gb2312,gbk 來加入多個字符集。

若是不想對錶結構進行修改或者從新編譯MySQL，也能夠在查詢語句的 order by 部分使用 CONVERT 函數。

好比 select * from mytable order by CONVERT(chineseColumnName USING gbk);
UTF8 默認校對集是 utf8_general_ci , 它不是按照中文來的。你須要強制讓MySQL按中文來排序。

explain分析

type——range/index
rows——數據查詢範圍
Extra——建議使用的關鍵字

分頁查詢優化

http://www.javashuo.com/article/p-ymihythh-bb.html

select * from orders_history where type=8 limit 100,100;
select * from orders_history where type=8 limit 1000,100;
select * from orders_history where type=8 limit 10000,100;
select * from orders_history where type=8 limit 100000,100;
select * from orders_history where type=8 limit 1000000,100;

隨着查詢偏移的增大，尤爲查詢偏移大於10萬之後，查詢時間急劇增長。
由於這種分頁查詢方式會從數據庫第一條記錄開始掃描，因此越日後，查詢速度越慢，並且查詢的數據越多，也會拖慢總查詢速度。

使用子查詢優化

select * from orders_history where type=8 and id>=(select id from orders_history where type=8 limit 100000,1) limit 100;
先定位偏移位置的 id，而後日後查詢，這種方式適用於 id 遞增的狀況。

使用 id 限定優化

select * from orders_history where type=2 and id between 1000000 and 1000100 limit 100;
這種方式假設數據表的id是連續遞增的，則咱們根據查詢的頁數和查詢的記錄數能夠算出查詢的id的範圍，可使用 id between and 來查詢
這種查詢方式可以極大地優化查詢速度，基本可以在幾十毫秒以內完成。限制是只能使用於明確知道id的狀況，不過通常創建表的時候，都會添加基本的id字段，這爲分頁查詢帶來不少便利。

能夠有另一種寫法：
select * from orders_history where id >= 1000001 limit 100;

關於數據表的id說明

通常狀況下，在數據庫中創建表的時候，強制爲每一張表添加 id 遞增字段，這樣方便查詢。

若是像是訂單庫等數據量很是龐大，通常會進行分庫分表。這個時候不建議使用數據庫的 id 做爲惟一標識，而應該使用分佈式的高併發惟一 id 生成器來生成，並在數據表中使用另外的字段來存儲這個惟一標識。
使用先使用範圍查詢定位 id （或者索引），而後再使用索引進行定位數據，可以提升好幾倍查詢速度。即先 select id，而後再 select *。
http://www.javashuo.com/article/p-qchoxqve-cc.html

Mysql性能優化

Mysql高性能優化規範建議