许多表或行,哪一个在SQL中更有效？

Question

我正在建立一个程序,存储公司的新闻标题及其各种来源的时间戳.

假设公司的数量是1000.它就像苹果,谷歌,微软......等.

所以我可以考虑两个选择.

1. 一个包含大量行的表(上面的代码只是一个例子).

   CREATE TABLE news
   (
       news_id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
       company VARCHAR(10) NOT NULL,
       timestamp TIMESTAMP NOT NULL,
       source TEXT NOT NULL,
       content TEXT NOT NULL,
       ...
   )
   
   // I also can make company and timestamp as primary keys,
      and news_id will be unique key.*
   

2. 1000表

   CREATE TABLE news_apple // and news_google, news_microsoft, news_...(x 1000)
   (
       news_id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
       timestamp TIMESTAMP NOT NULL,
       source TEXT NOT NULL,
       content TEXT NOT NULL,
       ...
   )
   

大多数时候,我会找到某个公司的新闻.假设每家公司有超过10000条新闻.我想知道如果我在第一个选项中使用'WHERE'子句,它将比第二个选项慢.

哪一个在性能方面更有效？为什么？

Answer 1

关系数据库旨在为每个表存储许多行.有一大堆机制可以促进大型表,例如:

• 用于加速搜索的任何字段组合的索引
• 页面缓存如此常用的页面保留在内存中
• 垂直分区(柱状数据库)以进一步加快请求速度
• 高级算法,例如散列连接和分组(至少在MySQL以外的数据库中)
• 使用多个处理器和磁盘来处理查询

将数据放在单个表中时,有一件事情比较困难,那就是安全性.事实上,在某些情况下,这是一个主要问题,基本上要求数据放在单独的表中.这些应用很少见.

为了举例说明多个表中存储数据的错误程度,可以想象在您的系统中,每个公司都有一条记录,并将其存储在表中.此记录存储有关公司的信息 - 例如姓名,地址等等.呼叫是100字节的信息.

在您的架构中,每个"公司"都有一个单独的表,因此每个表只有一行.该记录将驻留在一个数据页面上.数据页可能是16千字节,因此您要浪费大约15.9千字来存储这些数据.存储1000个这样的记录占用16兆字节而不是大约7页(112千字节).这可能是一个重大的性能打击.

此外,对于多个表,您没有考虑维护所有表并确保不同表中数据正确性的挑战.维护更新需要应用于数千个表,而不是少数几个.

Answer 2

我对许多表的经验,目前正在为一家拥有6000多张表并且不断发展的公司工作,这是管理众多表的难度.好处是减少表中的行数(我在其他公司有3000万行)这很好 - 但前提是你的所有表都有一个可管理的解决方案.

例如:6000+表实际上是酒店的房间号为Id(data_room#_hotelID),所以我可以编写存储过程,bash或php脚本来处理它们.

另一方面,许多行更简单,因为你需要处理更少的表,但是你需要开始创造如何将数据拉出来.您肯定希望在SQL WHERE子句中添加索引,但这很明显.

我过去用来管理大表的选项是:

1)以有意义的方式(如按字母顺序)插入自动增量数据 - 但是看到你的数据发生了很大的变化,这不是一个好的选择

2)将表加载到内存中 - 我不知道你在哪里托管这个,但我在内存中使用MySQL.我只知道有两种方法可以做到这一点:一种是在MySQL本身设置它,另一种是使用内存驱动器(使用计算机的一些内存)并将MySQL和它的数据移动到已安装的驱动器上(我是也用过Flash驱动器).

无论是更频繁地插入还是选择数据,您还需要考虑因素.

总结一下:

• 如果您选择制作多个表格,请确保它们没有大量数据并且您可以管理所有表格.

• 如果您使用更少的表和更多的行,请使用索引,RAM驱动器,缓存来加速从大型表中获取数据的过程.

这是我的两分钱,我希望它对你有所帮助!