在以往的一些面试过程中，我发现了一些有趣的回答，它们很容易被为归类为“错误答案”。但有时，这些答案却发人深省或包含深刻的含义。本文涉及一些常见的 MySQL 问答，这些问答可能看起来“错误”或“有趣”，但实际上还有更多内容。我将分享一些看似“错误”或异想天开的答案，并仔细研究它们提供的宝贵经验和观点。

让我们来一次 MySQL 面试吧！

1一些有趣的问答

问：如何改进慢查询？

答：我们根本不执行查询。避免的查询就是改进。

虽然有些玩笑，但在执行查询之前应该仔细考虑是否有必要。避免不必要的查询并仅获取所需的数据可以显着优化查询的性能。

对于无法避免的查询，改进方法是：

• 监控慢查询日志并使用 pt-query-digest 生成慢查询的摘要报告。
• 在 MySQL 中使用 EXPLAIN 语句来了解查询执行计划，提供对表访问顺序、索引使用情况和潜在性能瓶颈的见解。

补充阅读

《如何查找和调优慢 SQL 查询》^[1]

问：你们的故障恢复策略是什么？

答：我们的主数据库下有一个副本。

准备副本似乎是一个简单的答案，但它不是一个全面的故障恢复策略。实际上，仅依靠主服务器下的副本往往是不够的。

策略中，必须考虑多个方面，比如：

• 数据备份
• 高可用性
• 故障转移机制
• 异地存储

虽然拥有副本有利于负载平衡和读取扩展，但它并不能涵盖所有故障场景。

补充阅读

《为什么不能依赖副本进行灾难恢复的快速说明》^[2]

问：延迟副本怎么样？

答：不错，故障也延迟了。

好吧，这是一场迟来的灾难。🙂

延迟的程度，很大一部分原因取决于您的监控策略的强度以及您对灾难恢复呼叫的反应速度。

与生成环境的主副本相比，延迟副本肯定会通过提供额外的灾难恢复保护层来补充常规实时副本。

如果延迟副本托管在同一基础设施/数据中心上，则它很容易受到影响主副本的相同故障的影响。

它的价值是有助于提供良好的备份计划，以防止人为错误、逻辑错误、数据损坏等。

补充阅读

《MySQL 备份和恢复最佳实践终极指南》^[3]

问：有哪些不安全做法？

答：在my.cnf 文件中存放密码。

my.cnf 文件通常用于存储 MySQL 的登录凭证，允许用户在不显式提供凭据的情况下连接到数据库。我们都知道，在此文件中保存明文密码存在重大安全风险，因为如果文件系统遭到破坏，可能会导致未经授权的访问。在命令提示符下使用密码时也存在同样的风险。

补充阅读

《无需密码即可使用 MySQL（并且仍然安全）》^[4]

问：如何对一张 10T 的表进行变更操作？

答：我不会。

自然的回答可能是建议使用 pt-online-schema-change 或 gh-ost 等工具寻找 ONLINE ALTER 选项。虽然这些答案看起来是正确的，但是考虑到该类行为所需的时间和资源，真的能够对一张 10T 表进行变更吗？显然，10T 只是一个数字，代表一个巨大的表。

反问：为什么数据库中有这么大的表？

因为表的体积已经达到 TB，很可能会进一步增长；应该有一个归档策略或对应用程序逻辑进行一些更改以获得可管理的表大小。

生产中的大型表会降低查询性能，导致读写效率低下，备份恢复速度变慢，并给应用程序更改和数据库升级带来挑战。了解和监控系统中表的增长并制定可能的表归档策略非常重要。

2结束语

在结束之前，感谢你对以上 MySQL 相关问题的阅读思考。最后，让我们强调在解决问题时，对那些显而易见的答案重新思考的重要性。有时，正确的答案需要更深入的研究，这才是真正的理解所在。

happy MySQL-ing！

参考资料

SQLE 是一款全方位的 SQL 质量管理平台，覆盖开发至生产环境的 SQL 审核和管理。支持主流的开源、商业、国产数据库，为开发和运维提供流程自动化能力，提升上线效率，提高数据质量。

SQLE 获取

🔗 Github https://github.com/actiontech/sqle

📚 文档 https://actiontech.github.io/sqle-docs/

💻 官网 https://opensource.actionsky.com/sqle/

👥 微信群 添加管理员微信 ActionOpenSource