大型数据库表的设计技巧答案

【问题标题】：Design tips for large database table大型数据库表的设计技巧
【发布时间】：2019-02-05 14:23:56
【问题描述】：

我有一个巨大的数据库表（数百万条记录）。目前我们的应用程序仅位于加拿大，但现在我们正在进入其他国家/地区，因此每个国家/地区将添加数百万条数据。我应该为每个国家/地区创建单独的表还是保留一张大表？我正在使用 Cakephp 2.x，mysql 5.6 这张表会有很多读写操作。单独表的问题是，由于我使用模型 (MVC) 进行数据库操作，我将不得不为每个国家/地区创建单独的模型，并将它们组合起来用于报告目的将是一团糟。另一方面，将所有内容保存在一个表中会对系统造成很大负担。在这种情况下，索引会有所帮助吗？

【问题讨论】：

Topicstarter 如果您遵循 @marekful 的建议，请确保使用 LIST 作为 Partitioning Type，假设国家/地区基于 country_id
“我应该将其更改为数值吗？（1 代表 ca，2 代表我们等）”是的，理想情况下，您应该有一个包含名称和 id 的国家/地区表，并且在您的数据中有一个 country_id 列表。
在某些时候，您应该考虑寻求专业帮助。我想你可能就是那个时候。
要以任何有意义的方式回答都远远不够广泛。 “很多”不清楚，Cake 与问题完全无关。如果设计得当，任何现代 SQL 数据库都不会出现数百万甚至数十亿条记录。哦，我也不同意@RaymondNijland，而不是 Ids 使用 2 或 3 char ISO 3166-1 代码。
@RaymondNijland 这些天我不认为额外的几个字节是一个问题，特别是当你处理像 CQRS 这样的东西时，例如你可能有一个用于你的写入模型的关系数据库和 ES 或 MongoDB你的阅读模型。当然，您会“浪费”空间，但会获得其他优势。世界不是二元的，有灰色阴影。 ;) 我指的是整体设计，而不仅仅是索引。

标签： mysql cakephp database-design orm

【解决方案1】：

常见问题；常见答案：不要制作很多“相同”的表格。

除了极少数类型的查询外，不要使用PARTITION。最常见的是滑动时间刻度，需要定期删除“旧”行（通过DROP PARTITION）。 PARTITIONing 很少帮助 SELECT 提高性能。

（十亿行是“巨大的”；数百万行是相当可行的。）

索引对于任何重要的数据库表都是强制！

使用country_code CHAR(2) CHARACTER SET ascii。那是 2 个字节（几乎和 1 个字节 TINYINT 一样小，而且对人类更友好。当然，1MB 代表一百万行；但换个角度看——它大约是文件大小的 1%表，可能需要 ~100 字节/行。

至于“索引权”——您必须以SELECTs 开头，以确定需要哪些索引。

您提到了“报告”。这可能需要构建和维护汇总表。（再次，让我们看看SELECTs。）

【讨论】：

这意味着我不应该使用分区并且应该保留在一个表中？索引是否足以优化选择查询？
@ParthPatel - 没有人能看到SELECTs（和UPDATEs，如果它们不重要的话）来回答这个问题。我可以编写一个 2 行表和一个 SELECT，这将花费数小时，然后使服务器崩溃。（但您不会那样做，对吗？）..... 我可以向您展示在 billion-row 表上在 10 毫秒内运行的查询。