【问题标题】:SQL Indexing for search用于搜索的 SQL 索引
【发布时间】:2014-11-12 01:29:09
【问题描述】:

假设我在 mysql 中得到了这张表

ID Col1 Col2 Col3 Col4  

ID 列是主键,其他列可以是外键,也可以根本没有键。

这些列的任何组合都可以在搜索时在WHERE 语句中使用。例如,用户可能会询问结果where Col1 = 1 and Col3 = 100 |或类似Col2 = 10 and Col3 < 1000 and Col4 > 0

随着用户发布/删除/修改,表格会经常更新。我应该如何索引该表以加快搜索时间,因为该表可能会随着时间的推移而变得非常大。

我目前正在使用 MySQL,但如果答案不限于 MySQL,那将是理想的,因为我可能希望有一天将其移至 SQL Server

【问题讨论】:

  • 相当大”有多大?几百万条记录?更多?
  • @PM77-1 对之前的评论感到抱歉,可能是几百万。如果可能,请解释如果是几十万或几百万会有什么不同
  • @PM77-1 抱歉,我的单位弄错了……可能是几百万。预计会低于 2000 万,但我没有预言家可以看到未来
  • 我将创建 4 个单独的索引(在每列上)并使用膨胀表(具有最大预期记录)查看搜索速度提高了多少和/或 CRUD 速度降低了多少。
  • @PM77-1 好吧,既然它是关于索引的,我需要知道分布来模拟它,如果我只是让所有 Col1 = 1,那么如果我做类似的事情,搜索会非常快Col1 = 0 和 (...)。问题是我不知道值的分布是什么

标签: mysql sql sql-server indexing


【解决方案1】:

如果可以在 WHERE 子句中使用任何列组合,并且每种组合的可能性相同,那么您可能不会比创建四个索引更好,每列一个。

但是,在现实世界中,几乎可以肯定,每种组合都具有同样的可能性。您可以通过两种不同的方式来解决这个问题。 (不包括上面那个。)

  1. 创建no索引,等待人们抱怨性能。然后创建与投诉相关的索引。 (但有些人会受苦而不是抱怨。)
  2. Log all the queries,并根据 WHERE 子句中使用的列的实际分布创建索引。

拥有大量索引会占用空间,但现在空间很便宜。我认为唯一的风险是可能会混淆查询优化器。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2011-02-21
    • 2010-10-31
    • 2011-03-30
    • 1970-01-01
    • 2017-07-27
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多