【问题标题】:mysql index VS columnmysql索引VS列
【发布时间】:2012-09-26 10:01:58
【问题描述】:

请问用哪种方式设计表查询比较快?

案例A

图像表

身份证

1_20120930_aaaaa

9_20120930_ccccc

2_20120930_aaaaa

5_20120930_ddddd

3_20120930_vvvvv

1_20120930_bbbbb

SELECT * FORM image WHERE id LIKE '1_%';


案例 B

图像表

标识 |日期 | user_id

aaaa|20120930|1

cccc|20120930|9

aaaa|20120930|2

dddd|20120930|5

vvvv|20120930|3

bbbb|20120930|1

SELECT * FROM image WHERE user_id = '1';

谢谢!!

【问题讨论】:

  • 第二个,如果你看到有人使用你的第一个例子中展示的设计——不要再和那个人说话了。另一方面,也不要自己做,这在多个层面上都很糟糕(即使从非程序员的角度来看,这样做也不合逻辑)。
  • 哈哈,我只是好奇案例A也可以,但我没有看到有人这样做,但我需要知道原因?!
  • 我发现了一些有趣的东西stackoverflow|mysql-like-performance-boost
  • Erm,因为它完全违背了使用数据库的目的。您必须扫描每条记录才能找到以“1_”开头的内容。目前尚不清楚每个下划线之后的每一件事是什么,最后 - 从计算的角度来看,扫描所有记录而不是扫描仅属于 ID = 1 的用户的记录是否更容易?基本上 - 第一种方法中没有什么是好的。
  • 另外,对于您的最后评论 - 索引并不是让一切凭空运转的魔术棒。人们经常滥用它们,认为一切都会在一秒钟内变得超音速。我不知道您的知识水平如何,但是您链接的答案和您的问题没有任何共同点。

标签: mysql indexing multiple-columns


【解决方案1】:

肯定是CASE B。因为当你使用like运算符时,即使你在id列上定义了索引,它也不会使用索引。所以在case B,你可以在id中创建一个索引并在where子句中使用它更快地从表中检索数据。

【讨论】:

  • 第一个也使用索引,因为百分号的位置。但你是对的,第二个比第一个快。
  • 案例 A 的索引远大于案例 B 的索引。案例 A 的索引将被完全遍历,案例 B 的索引将进行 1 次查找。案例 A 中的索引完全没有意义。
  • 这不是“完全没有意义的”。索引是一个 B 树,所以它应该只找到前缀“1_”的节点并返回该子树中的所有内容。当您查找具有公共前缀的行时,B 树非常有效。
猜你喜欢
  • 2012-01-03
  • 1970-01-01
  • 1970-01-01
  • 2015-03-26
  • 2014-01-04
  • 1970-01-01
  • 2016-01-05
  • 2011-02-22
  • 2016-09-12
相关资源
最近更新 更多