【问题标题】:How to get faster SELECT indexes?如何获得更快的 SELECT 索引?
【发布时间】:2021-04-03 23:02:21
【问题描述】:

这是我的表的结构。

create table bids
(
    id           int unsigned auto_increment
        primary key,
    user_id      int unsigned                        not null,
    shipment_id  int unsigned                        not null,
    amount       double(8, 2)                        not null,
    commission   double(8, 2)                        not null,
    invoice_id   int unsigned                        null,
    created_at   timestamp default CURRENT_TIMESTAMP not null,
    accepted_at  timestamp                           null,
    retracted_at timestamp                           null
)
    collate = utf8mb4_unicode_ci;

create index bids_shipment_id_index
    on bids (shipment_id);

create index bids_user_id_index
    on bids (user_id);

create index bids_user_id_shipment_id_index
    on bids (user_id, shipment_id)

表格有大约 60M 行

像这样运行一个简单的查询:SELECT * FROM bids WHERE user_id = 3344; 大约需要 2 秒。

如何让这个查询运行得更快?

【问题讨论】:

  • 您已经在user_id 上建立了索引,因此您无能为力。 --- 注意索引bids_user_id_index是多余的,因为2列索引bids_user_id_shipment_id_indexuser_id开头,所以你应该删除索引bids_user_id_index以提高插入性能。
  • 不要发布表格图片。将CREATE TABLE 和在本例中的CREATE INDEX 语句发布为text
  • 你可以试试OPTIMIZE TABLE。这其中是否成功主要取决于被查询的表的碎片化。
  • 表使用的是哪个引擎?
  • @RickJames InnoDB.

标签: mysql database indexing


【解决方案1】:

正如 Andreas 上面评论的那样,如果查询使用了索引,您至少已经有两个可能有帮助的索引。

您应该使用EXPLAIN 确认优化器正在为您的查询选择索引。优化器可能出于某种原因拒绝使用索引。例如,如果 user_id 3344 出现在大量行上,优化器可能会决定索引不会保护任何工作。

出于同样的原因,像 “the” 这样的常用词不包含在书后的索引中。在一本书的索引中查找一个常用词是浪费时间,因为它只会告诉您该词出现在本书的大多数页面上。阅读本书的每一页会更容易,从头到尾。

您尚未分享有关 MySQL 服务器调优选项的任何详细信息。可能您的 innodb 缓冲池容量不足,并且查询从磁盘读取过多,然后一遍又一遍地从缓冲池中逐出页面。您的缓冲池大小应与数据集成比例。我用于许多应用程序的一个很好的起点是缓冲池与磁盘上的数据大小之间的比率为 1:10。

检查缓冲池大小:SELECT @@innodb_buffer_pool_size;

查看数据大小:SELECT SUM(data_length+index_length) from INFORMATION_SCHEMA.TABLES WHERE ENGINE='InnoDB';

您尚未描述服务器规格。对于这种规模的数据,您是否有动力不足的服务器?您使用老式的旋转磁盘还是 SSD 存储?数据是存储在 NFS 之类的远程卷上,还是在 AWS 中,是 EBS 吗?远程卷肯定会慢很多。使用本地连接的高速存储。

您还没有描述在您的数据库服务器上运行的其他内容。服务器是否也在运行要求苛刻的应用程序?提高性能的一个好方法是在专用服务器上运行数据库,而没有其他数据库或应用程序竞争资源。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2013-08-19
    • 2023-03-24
    • 2015-10-21
    • 1970-01-01
    • 1970-01-01
    • 2010-12-21
    • 2019-03-16
    相关资源
    最近更新 更多