MySQL性能問題與簡單的查詢

我試圖運行一個或多或少的簡單查詢約100000條目（大小：2319.58MB;平均：24KB預行）的MySQL表上。MySQL性能問題與簡單的查詢

這是查詢：

SELECT 
    n0_.id AS id0, 
    n0_.sentTime AS sentTime1, 
    n0_.deliveredTime AS deliveredTime2, 
    n0_.queuedTime AS queuedTime3, 
    n0_.message AS message4, 
    n0_.failReason AS failReason5, 
    n0_.targetNumber AS targetNumber6, 
    n0_.sid AS sid7, 
    n0_.targetNumber AS targetNumber8, 
    n0_.sid AS sid9, 
    n0_.subject AS subject10, 
    n0_.targetAddress AS targetAddress11, 
    n0_.priority AS priority12, 
    n0_.targetUrl AS targetUrl13, 
    n0_.discr AS discr14, 
    n0_.notification_state_id AS notification_state_id15, 
    n0_.user_id AS user_id16 
FROM 
    notifications n0_ 
    INNER JOIN notification_states n1_ ON n0_.notification_state_id = n1_.id 
WHERE 
    n0_.discr IN (
    'twilioCallNotification', 'twilioSMSNotification', 
    'emailNotification', 'httpNotification' 
) 
ORDER BY 
    n0_.id desc 
LIMIT 
    25 OFFSET 0

100和200sec之間的查詢。

這是創建表的語句：

CREATE TABLE notifications (
    id INT AUTO_INCREMENT NOT NULL, 
    notification_state_id INT DEFAULT NULL, 
    user_id INT DEFAULT NULL, 
    sentTime DATETIME DEFAULT NULL, 
    deliveredTime DATETIME DEFAULT NULL, 
    queuedTime DATETIME NOT NULL, 
    message LONGTEXT NOT NULL, 
    failReason LONGTEXT DEFAULT NULL, 
    discr VARCHAR(255) NOT NULL, 
    targetNumber VARCHAR(1024) DEFAULT NULL, 
    sid VARCHAR(34) DEFAULT NULL, 
    subject VARCHAR(1024) DEFAULT NULL, 
    targetAddress VARCHAR(1024) DEFAULT NULL, 
    priority INT DEFAULT NULL, 
    targetUrl VARCHAR(1024) DEFAULT NULL, 
    INDEX IDX_6000B0D350C80464 (notification_state_id), 
    INDEX IDX_6000B0D3A76ED395 (user_id), 
    PRIMARY KEY (id) 
) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE=InnoDB; 

ALTER TABLE notifications ADD CONSTRAINT FK_6000B0D350C80464 FOREIGN KEY (notification_state_id) REFERENCES notification_states (id) ON DELETE CASCADE; 
ALTER TABLE notifications ADD CONSTRAINT FK_6000B0D3A76ED395 FOREIGN KEY (user_id) REFERENCES users (id) ON DELETE CASCADE;

這些查詢由Doctrine2（ORM）創建的。我們在運行Debian 6.0.7的虛擬機（1GB RAM，單核）上使用MySQL 5.5.31。爲什麼查詢的性能如此糟糕？這是數據庫設計錯誤嗎？還是僅僅爲了處理這些數據量而使用vbox？

來源

2013-06-25 Frido

上DISCR列添加一個索引：

ALTER TABLE `notifications` ADD INDEX `idx_discr` (`discr` ASC) ;

來源

2013-06-25 13:12:58 kmas

好點！我已經爲** discr **列添加了一個索引。 '創建索引discr_idx ON通知（discr）'。查詢運行時間不在0.1 - 0.5秒 – Frido

每次向查詢添加一個子句時，如果你的表是一個大的表（即使是小表），不要忘記索引這個列，否則MySQL將消耗大量的RAM，時間。但對於您的數據庫模式，最好爲您的「discr」（只有「discr_id」和「discr_label」列）屬性創建一個參考表，然後在「notifications」表中添加一個外鍵（discr_id）。性能會增加很多，因爲索引是整數而不是字符。 – kmas

你正在通過notifications.discr過濾，但似乎沒有索引。你有沒有試過在它上面添加索引？

來源

2013-06-25 13:10:12 rebroken

MySQL性能問題與簡單的查詢

回答

相關問題