實施綜合指數

Question

我一直在閱讀有關復合索引如何提高性能的信息，但在某些方面仍不清楚。 我有一個INNODB數據庫，其中有超過2000萬個條目，每個條目都有8個數據點。 在過去的幾個月中，其性能已大幅下降。 該服務器有6個內核，具有4GB內存，將很快增加，但是服務器上沒有跡象表明我的內存不足。 INNODB設置已在my.cnf中更改為；

innodb_buffer_pool_size = 1000M
innodb_log_file_size = 147M

這些設置在過去有所幫助。 因此，我的理解是，許多因素都可能導致性能下降，其中包括我本來就根本沒有索引的事實。 索引方法取決於運行的查詢的類型。 所以這是我的桌子

cdr_records | CREATE TABLE `cdr_records` (
  `dateTimeOrigination` int(11) DEFAULT NULL,
  `callingPartyNumber` varchar(50) DEFAULT NULL,
  `originalCalledPartyNumber` varchar(50) DEFAULT NULL,
  `finalCalledPartyNumber` varchar(50) DEFAULT NULL,
  `pkid` varchar(50) NOT NULL DEFAULT '',
  `duration` int(11) DEFAULT NULL,
  `destDeviceName` varchar(50) DEFAULT NULL,
  PRIMARY KEY (`pkid`),
  KEY `dateTimeOrigination` (`dateTimeOrigination`),
  KEY `callingPartyNumber` (`callingPartyNumber`),
  KEY `originalCalledPartyNumber` (`originalCalledPartyNumber`),
  KEY `finalCalledPartyNumber` (`finalCalledPartyNumber`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1

因此，通常，查詢將使用一個值，然后搜索callingPartyNumber，originalCalledPartyNumber和finalCalledPartyNumber，以在表中查找與其相關的所有條目。 因此，使用如上所示的單個索引毫無意義，因為我通常不會運行這樣的查詢。 但是，基本上晚上我還有另一份工作。

select * from cdr_records;

在這種情況下，聽起來似乎要有一個包含所有列的復合索引是一個好主意。 我理解正確嗎？

Answer 1

當您需要以相同的方式基於多個列進行選擇/排序/分組時，組合索引的好處就來了。

我記得有個很好的例子，我在某處讀過電話簿類比。 由於電話簿中的名稱是按字母順序排列的，因此您很容易對它們進行排序，並根據名稱的字母從左到右找到所需的名稱。 您可以想象這是名稱中字母的綜合索引。

如果名稱僅按首字母排序，隨后的字母混亂（單列索引），則在找到首個字母后必須瀏覽所有記錄，這將花費大量時間。

使用復合索引，您可以從左到右開始，並且很容易找到您要查找的記錄，這也是您不能使用例如復合索引的第二或第三列的原因，因為您需要以前的，以使其工作。 想象一下，試圖在電話簿中查找所有第三個字母為“ a”的姓名，這將是一場噩夢，您將為此而需要一個單獨的索引，如果您需要使用一個復合索引，而不使用該索引之前的其他列。

請記住，電話簿示例假定名稱的每個字母都是一個單獨的列，這可能會造成一些混淆。

組合索引的另一個強大優勢是獨特的組合索引，它使您可以對需要的數據使用更高的邏輯限制。 與性能無關，但我認為值得一提。

在您的問題中，您的sql沒有條件，因此不會使用任何索引。 始終建議使用EXPLAIN來查看發生了什么，您永遠無法確定！

Answer 2

不 ，在所有字段上設置復合索引不是一個好主意。 在字段中放置一個或多個索引取決於您的查詢。

注意： MySQL只能為每個查詢使用一個索引，並且僅當使用左側站點上的所有字段時才可以使用復合索引。 您不能使用所有字段。

示例：如果您在字段名稱，街道，數字上具有索引x ，那么當您查詢（在WHERE中）名稱或名稱和街道或名稱，街道和數字時 ，將使用此索引， 但如果僅搜索街道或街道數字則不會使用該索引。

要確定索引是否與查詢良好配合使用，請將EXPLAIN放在查詢之前，然后可以查看查詢中使用的索引。