我有一個MySQL數據庫中的表,大約有25000條記錄。每個記錄有大約200個字段,其中許多是TEXT。關於結構我沒有辦法做到 - 這是從具有16年記錄的舊平面文件數據庫遷移而來的,許多字段都是「筆記」類型的自由文本條目。MySQL通過語句提高訂單的速度
用戶可以查看任意數量的字段,並按任何單個字段和任意數量的限定符進行排序。這種情況有很大的放緩,通常需要幾秒鐘,有時甚至需要7-10秒鐘。
一個例子聲明可能是這樣的:
select a, b, c from table where b=1 and c=2 or a=0 order by a desc limit 25
從未有一個明星選,始終有一個極限,所以我不認爲語句本身才能真正得到很多優化。
我知道索引可以幫助加快速度,但由於無法知道要排序哪些字段,因此我必須對所有200列進行索引 - 我讀過的有關此列表的內容似乎沒有一致。我知道在插入或更新記錄時會出現放緩,但假設這是可以接受的,建議在每列中添加一個索引?
我已閱讀關於sort_buffer_size,但它似乎就像我讀的最後一件事情衝突 - 增加此值或任何其他類似的值(read_buffer_size等)是可取的嗎?
此外,主要標識符是他們在九十年代提出的一種瘋狂模式。這是PK,因此應該通過成爲PK來編制索引(對吧?)。記錄已經(並且已經)提交給州和他們的客戶,我不能改變格式。這個列需要根據已經存在的邏輯進行排序,這涉及到一個存儲過程,其中包含字符串連接和子串匹配。這種排序特別慢,似乎並沒有緩存,即使這一個字段是索引,所以我不知道是否有什麼我可以做的,以加快對這個特定領域的排序(這是默認順序由)。
TYIA。
我認爲現在是時候重建你的表和數據庫結構,即使你說你不能這樣做。您至少可以查看右列類型的所有列。 – 2012-03-06 11:12:41
@PeterKiss無處不在我能夠使用更優化的數據類型,但是正如我所提到的,其中很多是「筆記」類型字段。任何超過我所做的事情都不會發生。沒有問題,它運行良好 - 瓶頸就是這樣。 – momo 2012-03-06 11:15:33
如果我是你,我會監視所有在後臺查詢(又名保存所有查詢,如果可能的話)然後我會運行他們與解釋關鍵字和收集最常用的列和建立他們的sima索引。列上的單個索引不會幫助! – 2012-03-06 11:19:47