简单查询的 MySQL 性能问题

标签 mysql sql linux doctrine-orm debian

我正在尝试对包含大约 100000 个条目的 MySQL 表运行一个或多或少的简单查询(大小:2319.58MB;平均:前行 24KB)。

这是查询:

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 到 200 秒之间的查询。

这是表的创建语句:

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 内存,单核)上使用 MySQL 5.5.31。为什么查询的性能如此糟糕?是数据库设计错误还是 vbox 太小无法处理如此大的数据量?

最佳答案

在 discr 列上添加索引:

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

关于简单查询的 MySQL 性能问题,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/17298163/

相关文章:

即使积压队列已满,客户端也会连接到 TCP 迭代服务器

mysql - 从多个 Excel 文件更新并添加 SQL 数据

MySQL(SQLite): insert rows based on a query with multiple rows result

linux - 如何使用一系列参数调用期望脚本

sql - 在大型数据集上优化 Oracle SELECT

mysql - MySql 过程中的 DECLARE 变量错误

linux - 坏 block 与分区相关还是永久相关?

php - 从特定列检索特定数据

php - 在数据库 'within this week' 中查询日期

sql - 在关系数据库中存储分层数据有哪些选项?