这听起来可能是一个笼统的问题，但我有一些想法可以通过在这里分享来发展。
我们的应用程序有几张超过 1000 万条记录的表；查询它们大约需要 40 秒。我们遵循了已知的数据库设计实践，例如使用主键、索引等。我们也尝试过归档旧行和表拆分等，但仍然没有那么令人印象深刻。
该应用程序是数据密集型应用程序，但我知道尽管银行等许多网站确实拥有大量数据，但它们仍然具有良好的性能。我不是数据库专家；有人可以在这里指出我所缺少的吗？
会有一些标准技术，如数据库集群等，有些是我的基础设施不允许的。
与原始存储相比，是否可以以更处理的格式存储数据？数据库设计中是否出现了新的设计实践？我可以轻松迁移到 NoSQL 吗？NoSQL 有多好？
一千万行并不是那么多。逐个调整您的查询。如果您有一个需要 40 秒的查询，请找出它是哪一个并修复它。在未索引的 where 子句中使用单个列可以使性能从 0.0001 秒变为 40 秒。大多数数据库都有“解释查询”功能，可以告诉您查询是如何执行的。
我最近处理的一个小型“大数据”问题有 1000 亿行——10 TB 左右的压缩数据。
如果您还没有弄清楚查询速度慢的原因，那么您可能甚至不应该考虑非 RDBMS 解决方案。
这里有三个非常容易实施的技巧，可以为您带来巨大的性能提升。
1 确保尽可能使用内部连接而不是 WHERE 子句。
例如，写
SELECT LastName, Address FROM Customer INNER JOIN CustomerAddress ON Customer.ID = CustomerAddress.CustomerID
代替：
选择姓氏、来自客户的地址、客户地址，其中客户.ID = 客户地址.客户ID
2 避免在 WHERE 子句中使用函数。
例如，
WHERE left(City,1) = 'M'
将导致整个表的索引扫描（即使是 City 不以“M”开头的行）
相反，使用
WHERE City like 'M%'
所有其他函数也是如此，例如 Datediff、Upper 等。
3 确保在您使用 WHERE 子句的每一列上都有一个索引。