今天遇到一个SQL要跑5462秒，执行计划走错了，成本估算得不对，以致走了索引而不是全表扫描，连接顺序也不对了，由于没有分区裁剪，所以猜想是timestamp参数类型惹的祸，一查字段类型果然是date, 这次是JDBC客户端程序提交的，JAVA开发人员大多不太注意这一点，date与timestamp不分，date字段赋timestamp参数很容易引发问题，我遇到好几次了，主要表现在分区裁剪不能实现，rows估算错误 ，相反若是timestamp类型，赋date参数，好像没什么问题，估计这是date与timestamp的复杂度不同导致的，timestamp更复杂，底层的存储方式也不一样，绑定变量窥探时，估计不好识别，所以支持不佳；
所以，不需要精确到毫秒的，建议少用timestamp,而不管用哪种，都要注意字段类型与参数类型要一致才是最合适的；
所以，不需要精确到毫秒的，建议少用timestamp,而不管用哪种，都要注意字段类型与参数类型要一致才是最合适的；
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/13365316/viewspace-2123195/ ，如需转载，请注明出处，否则将追究法律责任。
上一篇：
oracle大师们的blog抓取脚本
请登录后发表评论
登录
全部评论
