MySQL - 限制 30 或创建视图或非规范化的 INNER JOIN 12 表？答案

【问题标题】：MySQL - INNER JOIN 12 Tables with LIMIT 30 or Create View or Denormalization?MySQL - 限制 30 或创建视图或非规范化的 INNER JOIN 12 表？
【发布时间】：2018-04-19 12:44:45
【问题描述】：

我正在使用 MySQL，所有事务的规范化表。

现在，我需要将数据作为日志获取，但它需要加入超过 12 个表来记录我们需要查看的所有数据，只有最后 30 个提交的数据（完成/拒绝）会显示在分页中（日志第 1 页）但仍有最后 30 个分页。

9 INNER JOIN
3 LEFT JOIN (It's Admin Order Form when customer Ordering via Offline (friend))
WHERE order_status = 1 OR order_status = 2 (done & reject)
ORDER BY order_date DESC
LIMIT 30 (limiting 30 per page with pagination)
The order data is more than 2.000.000 rows for 4 tables in INNER JOIN connected in PK & FK.

如果我要加入 12 个表，或者我应该做其中的 1 个，有什么问题吗？

1. Create View in MySQL 
**OR**
2. Denormalize data (Create 1 more table for order_log), but I think it would
cost so many storage size
**OR**
3. Using SSD ?

有时我们需要确保通过标准化保存存储空间，有时我们需要更快的性能。（但由于数据大小，仍然不想对日志使用非规范化数据）。

有什么解决办法吗？谢谢。

【问题讨论】：

ORDER BY order_id DESC LIMIT 30 可能很难正确优化，因为 MySQL 优化器可以选择以不同的顺序访问表，并且需要再次使用快速排序算法来对结果进行排序。而且由于记录量很大，MySQL 优化器很可能需要使用临时表。
真的很抱歉，ORDER BY order_date DESC LIMIT 30 是正确的查询。
不应该是LIMIT 0,30，然后是LIMIT 30,30，以此类推吗？
如果没有完整的查询，很难说是否可以使用一些优化。例如，可以将一个或多个表作为子查询连接，其条件会减少主查询中涉及的行数。在程序员看来，创建视图可以简化您的查询，但仍然是服务器必须运行的查询，因此对性能没有帮助。

标签： mysql performance

【解决方案1】：

我依赖。

VIEW 只是语法糖。它没有提供额外的性能。但是，它可能使您的 SQL 更易于阅读。
去国有化可能有帮助。重新制定可能会有所帮助。更重要的是，首先在查找 30 行时可能会有所帮助。然后处理JOINs的其余部分。（如果没有看到查询，我无法更具体，包括哪些列在哪些表中。）
SSD 将帮助如果您受 I/O 限制。由于有数千行，您不太可能受到 I/O 限制。一百万行可能会有所不同。（需要更多信息来详细说明。）
不要规范化“连续”值，例如 FLOATs 或 DATETIMEs。这很可能使“范围”测试效率低下。 More discussion.
请提供SHOW CREATE TABLE、EXPLAIN SELECT ...
ENUMs 有时是节省空间和避免标准化的好方法。

【讨论】：

能否请您详细说明不规范化连续数据的点，因为I can't understand it 我相信这是非常重要的一点。谢谢里克先生
@Accountantم - 我有responded。如果仍然不清楚，也许那里的讨论会改善它。我没有看到那个问题，因为我只拖钓了某些 [标签]。（Rick 的 RoT 是单行的；没有详细说明的余地。）
谢谢你，顺便说一句，我在问这个问题的那天notified你，但看起来你没有注意到，我很抱歉
@Accountantم - 我被捆绑了几个月；我猜它从裂缝中溜走了。我很乐意详细说明您喜欢的任何内容。
您好，您能提供更多示例吗？非常感谢@RickJames。 19 小时后结束