最近在做一个海量数据的查询系统，每天会在凌晨插入20M行数据左右，一个月数据在550M行左右，通过索引等方法，基本上能实现不错的查询性能。不过，该月数据会一次性地
被删除为若干个月后的数据清空空间，我们是用TRUNCATE语句来清空的。结果在QA测试时需要对清空、重装载数据的过程进行功能、性能测试，发现不定地会出现在重装一天数据后，就导致数据查询
急剧变慢，基本无法得到查询结果。甚至于明知查出来的数据会很少，或者索引范围很小。问题是用于分块的一个分区键值表被用来限定大数据表查询范围，如果用分工健值表的主键来唯一确定大数据表范围，则没有性能
变慢问题，而通过分区键值表得到不止一个值，即便是关联的数据更少或差不多，则查询无解。通过执行计划跟踪，发现分区键值表无法很好地使用其表上所建索引，而直接导致在大数据表上做全表扫描。奇怪的是，唯一确定就能用到索引，唯二确定就不能用到索引，
而且还不是100%的出现这个情况，不过有一定可能重现。
经过分析，发现数据字典中一些关于大数据表的统计数据没有得到及时更新，让查询优化引擎认为数据量很小，不需要索引能更快得到结果，尽管这不是现实的情况？！反正手工改变该统计量后，查询速度就正常了。因为不能在项目起来后用DBA用户手工管理，就采取在导入
被删除为若干个月后的数据清空空间，我们是用TRUNCATE语句来清空的。结果在QA测试时需要对清空、重装载数据的过程进行功能、性能测试，发现不定地会出现在重装一天数据后，就导致数据查询
急剧变慢，基本无法得到查询结果。甚至于明知查出来的数据会很少，或者索引范围很小。问题是用于分块的一个分区键值表被用来限定大数据表查询范围，如果用分工健值表的主键来唯一确定大数据表范围，则没有性能
变慢问题，而通过分区键值表得到不止一个值，即便是关联的数据更少或差不多，则查询无解。通过执行计划跟踪，发现分区键值表无法很好地使用其表上所建索引，而直接导致在大数据表上做全表扫描。奇怪的是，唯一确定就能用到索引，唯二确定就不能用到索引，
而且还不是100%的出现这个情况，不过有一定可能重现。
经过分析，发现数据字典中一些关于大数据表的统计数据没有得到及时更新，让查询优化引擎认为数据量很小，不需要索引能更快得到结果，尽管这不是现实的情况？！反正手工改变该统计量后，查询速度就正常了。因为不能在项目起来后用DBA用户手工管理，就采取在导入
一天数据后，进行大数据表分析强制更新统计数据，虽然分析该表会多出十多分钟处理，但总算解决了这个古怪问题。
本文转自 dannyy1026 51CTO博客，原文链接:
http://blog.51cto.com/dannyyuan/70762
