① mysql 增加排序 性能差很多 怎麼優化
1、ORDER
BY的索引優化。如果一個SQL語句形如：
SELECT
[column1],[column2],….
FROM
[TABLE]
ORDER
BY
[sort];
在[sort]這個欄位上建立索引就可以實現利用索引進行order
by
優化。
2、WHERE
+
ORDER
BY的索引優化，形如：
SELECT
[column1],[column2],….
FROM
[TABLE]
WHERE
[columnX]
=
[value]
ORDER
BY
[sort];
建立一個聯合索引(columnX,sort)來實現order
by
優化。
注意：如果columnX對應多個值，如下面語句就無法利用索引來實現order
by的優化
SELECT
[column1],[column2],….
FROM
[TABLE]
WHERE
[columnX]
IN
([value1],[value2],…)
ORDER
BY[sort];
3、WHERE+
多個欄位ORDER
BY
SELECT
*
FROM
[table]
WHERE
uid=1
ORDER
x,y
LIMIT
0,10;
建立索引(uid,x,y)實現order
by的優化,比建立(x,y,uid)索引效果要好得多。
MySQL
Order
By不能使用索引來優化排序的情況
*
對不同的索引鍵做
ORDER
BY
：(key1,key2分別建立索引)
SELECT
*
FROM
t1
ORDER
BY
key1,
key2;
*
在非連續的索引鍵部分上做
ORDER
BY：(key_part1,key_part2建立聯合索引;key2建立索引)
SELECT
*
FROM
t1
WHERE
key2=constant
ORDER
BY
key_part2;
*
同時使用了
ASC
和
DESC：(key_part1,key_part2建立聯合索引)
SELECT
*
FROM
t1
ORDER
BY
key_part1
DESC,
key_part2
ASC;
*
用於搜索記錄的索引鍵和做
ORDER
BY
的不是同一個：(key1,key2分別建立索引)
SELECT
*
FROM
t1
WHERE
key2=constant
ORDER
BY
key1;
*
如果在WHERE和ORDER
BY的欄位上應用表達式(函數)時，則無法利用索引來實現order
by的優化
SELECT
*
FROM
t1
ORDER
BY
YEAR(logindate)
LIMIT
0,10;
② mysql表數據已排序好，order by查詢速度會不會更快
不會更快
因為資料庫本身不知道這個數據是否有序.
orderby是資料庫查詢的最後一步.執行順序在 select, where等等過濾條件之後.
由於資料庫本身不知道是否有序,所以必然會執行orderby進行排序.只不過排序是在內存中進行判斷,並且排序的結果不需要變而已,但還是需要執行排序,進行數據比對.
所以不會更快.
ps:既然數據表已經是有序的...為什麼還要orderby排序?直接用limit進行切片就好了阿?這不是多次一舉嗎?
③ mysql 大數據量的表聯合查詢慢,如何處理
避免全表查詢，建立索引。order by
優化你的sql語句。
在where子句中盡量避免區域查詢，例如不等於，大於小於之類的操作符
like語句也會導致全表查詢
等等
④ mysql結構應該怎麼設置才能保證大數據量不慢
在Apache, PHP, MySQL的體系架構中，MySQL對於性能的影響最大，也是關鍵的核心部分。對於Discuz!論壇程序也是如此，MySQL的設置是否合理優化，直接影響到論壇的速度和承載量！同時，MySQL也是優化難度最大的一個部分，不但需要理解一些MySQL專業知識，同時還需要長時間的觀察統計並且根據經驗進行判斷，然後設置合理的參數。 下面我們了解一下MySQL優化的一些基礎，MySQL的優化我分為兩個部分，一是伺服器物理硬體的優化；二是MySQL自身(my.cnf)的優化。 (1) 伺服器硬體對MySQL性能的影響 a) 磁碟尋道能力（磁碟I/O）,以目前高轉速SCSI硬碟(7200轉/秒)為例，這種硬碟理論上每秒尋道7200次，這是物理特性決定的，沒有辦法改變。MySQL每秒鍾都在進行大量、復雜的查詢操作，對磁碟的讀寫量可想而知。所以，通常認為磁碟I/O是制約MySQL性能的最大因素之一，對於日均訪問量在100萬PV以上的Discuz!論壇，由於磁碟I/O的制約，MySQL的性能會非常低下！解決這一制約因素可以考慮以下幾種解決方案： 使用RAID-0+1磁碟陣列，注意不要嘗試使用RAID-5，MySQL在RAID-5磁碟陣列上的效率不會像你期待的那樣快； 拋棄傳統的硬碟，使用速度更快的快閃記憶體式存儲設備。經過Discuz!公司技術工程的測試，使用快閃記憶體式存儲設備可比傳統硬碟速度高出6－10倍左右。 b) CPU 對於MySQL應用，推薦使用S.M.P.架構的多路對稱CPU，例如：可以使用兩顆Intel Xeon 3.6GHz的CPU。 c) 物理內存對於一台使用MySQL的Database Server來說，伺服器內存建議不要小於2GB，推薦使用4GB以上的物理內存。 (2) MySQL自身因素當解決了上述伺服器硬體制約因素後，讓我們看看MySQL自身的優化是如何操作的。對MySQL自身的優化主要是對其配置文件my.cnf中的各項參數進行優化調整。下面我們介紹一些對性能影響較大的參數。 由於my.cnf文件的優化設置是與伺服器硬體配置息息相關的，因而我們指定一個假想的伺服器硬體環境： CPU: 2顆Intel Xeon 2.4GHz 內存: 4GB DDR 硬碟: SCSI 73GB 下面，我們根據以上硬體配置結合一份已經優化好的my.cnf進行說明： # vi /etc/my.cnf 以下只列出my.cnf文件中[mysqld]段落中的內容，其他段落內容對MySQL運行性能影響甚微，因而姑且忽略。 [mysqld] port = 3306 serverid = 1 socket = /tmp/mysql.sock skip-locking # 避免MySQL的外部鎖定，減少出錯幾率增強穩定性。 skip-name-resolve 禁止MySQL對外部連接進行DNS解析，使用這一選項可以消除MySQL進行DNS解析的時間。但需要注意，如果開啟該選項，則所有遠程主機連接授權都要使用IP地址方式，否則MySQL將無法正常處理連接請求！ back_log = 384 指定MySQL可能的連接數量。當MySQL主線程在很短的時間內接收到非常多的連接請求，該參數生效，主線程花費很短的時間檢查連接並且啟動一個新線程。 back_log參數的值指出在MySQL暫時停止響應新請求之前的短時間內多少個請求可以被存在堆棧中。 如果系統在一個短時間內有很多連接，則需要增大該參數的值，該參數值指定到來的TCP/IP連接的偵聽隊列的大小。不同的操作系統在這個隊列大小上有它自己的限制。 試圖設定back_log高於你的操作系統的限制將是無效的。默認值為50。對於Linux系統推薦設置為小於512的整數。 key_buffer_size = 256M # key_buffer_size指定用於索引的緩沖區大小，增加它可得到更好的索引處理性能。 對於內存在4GB左右的伺服器該參數可設置為256M或384M。 注意：該參數值設置的過大反而會是伺服器整體效率降低！ max_allowed_packet = 4M thread_stack = 256K table_cache = 128K sort_buffer_size = 6M 查詢排序時所能使用的緩沖區大小。注意：該參數對應的分配內存是每連接獨占！如果有100個連接，那麼實際分配的總共排序緩沖區大小為100 × 6 ＝ 600MB。所以，對於內存在4GB左右的伺服器推薦設置為6-8M。 read_buffer_size = 4M 讀查詢操作所能使用的緩沖區大小。和sort_buffer_size一樣，該參數對應的分配內存也是每連接獨享！ join_buffer_size = 8M 聯合查詢操作所能使用的緩沖區大小，和sort_buffer_size一樣，該參數對應的分配內存也是每連接獨享！ myisam_sort_buffer_size = 64M table_cache = 512 thread_cache_size = 64 query_cache_size = 64M 指定MySQL查詢緩沖區的大小。可以通過在MySQL控制台執行以下命令觀察： # > SHOW VARIABLES LIKE '%query_cache%'; # > SHOW STATUS LIKE 'Qcache%'; # 如果Qcache_lowmem_prunes的值非常大，則表明經常出現緩沖不夠的情況； 如果Qcache_hits的值非常大，則表明查詢緩沖使用非常頻繁，如果該值較小反而會影響效率，那麼可以考慮不用查詢緩沖；Qcache_free_blocks，如果該值非常大，則表明緩沖區中碎片很多。 tmp_table_size = 256M max_connections = 768 指定MySQL允許的最大連接進程數。如果在訪問論壇時經常出現Too Many Connections的錯誤提 示，則需要增大該參數值。 max_connect_errors = 10000000 wait_timeout = 10 指定一個請求的最大連接時間，對於4GB左右內存的伺服器可以設置為5-10。 thread_concurrency = 8 該參數取值為伺服器邏輯CPU數量×2，在本例中，伺服器有2顆物理CPU，而每顆物理CPU又支持H.T超線程，所以實際取值為4 × 2 ＝ 8 skip-networking 開啟該選項可以徹底關閉MySQL的TCP/IP連接方式，如果WEB伺服器是以遠程連接的方式訪問MySQL資料庫伺服器則不要開啟該選項！否則將無法正常連接！
⑤ mysql order by 排序效率慢 SQL 附上
既然查詢速度特別快 而且你也只需要排名前一百條的語句，可以用where語句再過濾一下，然後對查詢出來的語句再進行排序。相對來說需要排序的數據量會少一些。
例如：
1、select top 100 * from mytable order by operateDate；
2、select * from (select top 100 * from mytable ) a order by a.operateDate；
如果表內數據量比較大的話 ，2 的速度是優於1的。畢竟1是先對表內所有數據排序，然後再進行查詢，2隻需要排序過濾之後的數據。
⑥ MySQL外鏈接查詢加排序執行慢怎樣解決
mysql中的sql語句是按照從左到右，從上到下的順序執行的。
要優化的話先把能排除大部分記錄的條件判斷放在前面，若還是慢，則可以對某些欄位建立索引。
⑦ sql 分組數排序 速度太慢
分組聚合就會慢一些，首先看看where條件中的列名是否建立了索引、索引是否起作用。如實在不行，可以考慮使用物化視圖（使用你這個sql生成），並讓其自動更新，查詢時只查詢該視圖，速度就快了。（這樣做就把聚合計算時間分散了、碎片化了）。僅供參考。
⑧ mysql 中數據量大時超30萬，加上order by 速度就變慢很多，一般需要0.8秒左右，不加只需要0.01幾秒
那肯定的
ORDERY BY是要對某個欄位進行排序的，有人喜歡加索引解決，但是若是對於一個頻繁有寫操作的表來說，一個索引還好說，要是有多個索引，數據表的大小增加會相當驚人
另上，建議使用InnoDB引摯，有人說這樣速度會快很多
對於大數據級的資料庫來說，最關鍵的一步還是要優化好你的SQL，還有就是使用非常規的作法，供參考
1，以犧牲空間換取速度，就是說看能不能進行一些適當的緩存
2，以犧牲速度換取空間，這對於小空間容量的主機可以採用
⑨ mysql怎樣對臨時欄位高效排序（30萬條數據）
$sql = "SELECT t.*, f.name FROM threads t, forums f where f.fid=t.fid ORDER BY id=10000 desc , t.dateline DESC LIMIT 0, 10";
但效率比較差。
下面這個效率上會好一些
SQL code?
select * from (
(SELECT t.*, f.name FROM threads t, forums f where f.fid=t.fid id=10000)
union all
(SELECT t.*, f.name FROM threads t, forums f ORDER BY t.dateline DESC LIMIT 0, 10)
) t
order by id=10000 desc,datelineDESC LIMIT 0, 10
⑩ mysql大數據量情況下的排序
字元集很簡單，但是數據的排序需要通過SQL語句來協助完成，ORDER BY 語句，代碼如下：
// 假設你回已經成答功連接了資料庫($mysqli變數假設為連接的資源句柄)
// 通過對象方式設置字元編碼
$mysqli -> set_charset('utf8');
// 通過函數方式設置字元編碼
mysqli_set_charset($mysqli, 'utf8');
// 那麼接下來是數據排序的話，需要編寫一條SQL查詢語句(DESC 倒序排列 | ASC 正序排列)
$sql = "SELECT `欄位` FROM `表名` WHERE TRUE ORDER BY `欄位` DESC;";
如果還有什麼問題，歡迎追問~