有多少次你发现某个查询在针对经过清理的数据进行测试时能发挥充分的性能，但在生产环境中却只看到它停止一次？由于工作负载和数据量等环境之间的差异，这种情况一直在发生。因为这个原因，你可能会在生产环境中尝试你的查询。毕竟，调整生产查询的最快方法是在生产服务器上，不是吗？虽然这是正确，但仍有许多危险等待着那些愚蠢到无视保障措施和协议的人。在本文中，我们将探讨在生产环境中测试查询的一些相关风险。
一些需要考虑的风险
那些这样做的人要谨记“测试”的重点是你正在测试的东西有可能发生“坏事情”。你可能无法想到任何风险，但那是因为在你运行测试之前，你不知道并且不可能知道这些风险是什么。一些可能发生的坏事情包括：
逻辑数据损坏
INSERT 和 UPDATE 语句就其本质而言，它们很可能会使用虚假或格式错误的数据创建记录，或者没有正确实现参照完整性。此外，不良数据可能会破坏先前经过测试且表现良好的应用程序对数据的逻辑假设。如果应用程序遇到错误记录，它可能会导致“错误答案”甚至整个站点崩溃，直到发现损坏并手动修复为止。
性能下降
一个常见的情况是，你的测试应用程序正在执行你在开发实例中未识别的表扫描，因为该表仅有大约 10,000 条记录，而在生产中则有 1 亿条记录。一旦你的应用程序开始对一个或多个核心表进行表扫描，你的生产数据库可能会陷入死锁，直到你逐一终止查询。更糟糕的是，一旦你的应用程序用完所有可用的数据库连接，你甚至无法在数据库上打开命令 shell 来终止查询。
锁定问题
如果你忘记提交（COMMIT）一个事务，你可能会锁定一半的数据库，因为你的数据库连接池中有未提交的多语句事务。因此，客户操作可能会超时并随机死锁。
最终用户看到错误的数据
不良数据在许多层面都是一个问题。坏处可以是出售没有的库存，也可以是存在没有密码的用户帐户，这使你容易受到黑客攻击。一个相关的问题是忘记删除测试用户。由于你可能是唯一知道它们存在的人，因此它们可能会一直在那里，直到黑客发现你的“test123”用户的密码为“password123”。
未知和未定义的风险
还有无数其他灾难和毁灭的情况，只是受限于你的想象力或那些喜欢看着我们受苦和挣扎的更高权力者的......
到最近计算能力的提高，才可能在传统关系数据库中使用倒排索引总结
千万不要因为你“理解”你的代码就认为不会发生坏事。这个想法是疯狂的。你可能会暂时摆脱不好的事，甚至是好一阵子。尽管如此，总有一天事情会变坏。当真的发生了，就会变得非常糟糕。
