16 个解决方案
#1
优化数据库，增加索引，提高查询速度，加缓存 ，不要每次都跟数据库打交道，优化代码，做压力测试，找时间消耗点在哪
#2
检查数据库的瓶颈出现在哪，针对性进行优化。
#3
只有几百万数据，量其实是很小地。
我只是说一个原则吧。给领导看的东西（不管是一个领导还是30位领导），特别是经常需要展示的东西，不应该“进行统计计算”，应该“傻瓜化地读取报告结果”。比如说领导要看最近一分钟新统计出来的的全省的矿山的爆炸物使用情况分布图，那么图上的数据（可能有成千上万个标注，有几十个多边形区域），那么这些数据都应该是从“一个数据库表”傻瓜化地抓出来数据来展示的，而不应该临时统计。即使是“实时跳动”的数据，也应该是某些系统推送过来的，而不是自己去查询统计的。
如果涉及这类系统，那么它就是分层的。在底层系统之上有至少1、2层新的框架。
而那些“竖井式思维”的做法，则什么都临时查询统计。就容易死掉了。
我只是说一个原则吧。给领导看的东西（不管是一个领导还是30位领导），特别是经常需要展示的东西，不应该“进行统计计算”，应该“傻瓜化地读取报告结果”。比如说领导要看最近一分钟新统计出来的的全省的矿山的爆炸物使用情况分布图，那么图上的数据（可能有成千上万个标注，有几十个多边形区域），那么这些数据都应该是从“一个数据库表”傻瓜化地抓出来数据来展示的，而不应该临时统计。即使是“实时跳动”的数据，也应该是某些系统推送过来的，而不是自己去查询统计的。
如果涉及这类系统，那么它就是分层的。在底层系统之上有至少1、2层新的框架。
而那些“竖井式思维”的做法，则什么都临时查询统计。就容易死掉了。
#4
这种读写分离，预先统计，水平分割，垂直分割，SQL优化什么的都是必须要上的了啊
#5
其实许多东西如果你仔细看，你会发现要针对去解决的那些低级程序设计的毛病都是如出一辙的。只是我们不便过多地去说而已（因为许多人的天性就是懒惰、不愿意多干）。你说你要把一个数据库分成20个数据库pool，然后再把20个数据库分别逐一地部署成“一个Master+3个Slave”的，说起来确实是高大上令人振奋，但是有几个人愿意自己动手干和维护呢？
作为设计师，有什么我们需要前思后想，然后针对“懒人们”设计出不同的优化步骤来，所以复杂的系统的建设规划总是各不相同的。目的就是让一帮比较懒的程序员也能有兴趣去跟着开发，而不是一开始就被复杂性而吓退了。
作为设计师，有什么我们需要前思后想，然后针对“懒人们”设计出不同的优化步骤来，所以复杂的系统的建设规划总是各不相同的。目的就是让一帮比较懒的程序员也能有兴趣去跟着开发，而不是一开始就被复杂性而吓退了。
#6
我也遇类似的问题，正在寻找对应办法
#7
索引才是解决知道，不过索引我感觉经常要重建
#8
建立索引,速度嗷嗷提升。
#9
使用存储过程，将统计数据写入存储过程
#10
增加缓存memcache，redis
#11
几百万数据，缓存起来，用不了多少内存。
有什么需求，用什么数据结构，一般都有O(log(n))的更新方案，查询结果小的话应该都是0ms。
有什么需求，用什么数据结构，一般都有O(log(n))的更新方案，查询结果小的话应该都是0ms。
#12
索引，优化，统计放到后台运行
#13
除了优化还是优化，不过你可以自己加锁，行锁表锁，这样就可以避免死锁之类的问题发生
#14
查询的时候加nolock
#15
上面说的重建索引通过sql server维护计划定时自动过去（其实还有数据库碎片也需要定时整理），这是从存储的角度讲的
从逻辑上讲，有些统计数据的确不适合临时查询计算，会拖垮系统，这个时候就需要仔细分析业务，优化设计了
从逻辑上讲，有些统计数据的确不适合临时查询计算，会拖垮系统，这个时候就需要仔细分析业务，优化设计了
#16
一, 每一个用户不可能每次都需要用几百万数据库做基础是吧，取相关资料
二,某些计算不需要每次都计算的就可以省点时间。
三,找到关键点，看是链接数据库读取数据时的时间多，还是计算的时间 。
二,某些计算不需要每次都计算的就可以省点时间。
三,找到关键点，看是链接数据库读取数据时的时间多，还是计算的时间 。
#1
优化数据库，增加索引，提高查询速度，加缓存 ，不要每次都跟数据库打交道，优化代码，做压力测试，找时间消耗点在哪
#2
检查数据库的瓶颈出现在哪，针对性进行优化。
#3
只有几百万数据，量其实是很小地。
我只是说一个原则吧。给领导看的东西（不管是一个领导还是30位领导），特别是经常需要展示的东西，不应该“进行统计计算”，应该“傻瓜化地读取报告结果”。比如说领导要看最近一分钟新统计出来的的全省的矿山的爆炸物使用情况分布图，那么图上的数据（可能有成千上万个标注，有几十个多边形区域），那么这些数据都应该是从“一个数据库表”傻瓜化地抓出来数据来展示的，而不应该临时统计。即使是“实时跳动”的数据，也应该是某些系统推送过来的，而不是自己去查询统计的。
如果涉及这类系统，那么它就是分层的。在底层系统之上有至少1、2层新的框架。
而那些“竖井式思维”的做法，则什么都临时查询统计。就容易死掉了。
我只是说一个原则吧。给领导看的东西（不管是一个领导还是30位领导），特别是经常需要展示的东西，不应该“进行统计计算”，应该“傻瓜化地读取报告结果”。比如说领导要看最近一分钟新统计出来的的全省的矿山的爆炸物使用情况分布图，那么图上的数据（可能有成千上万个标注，有几十个多边形区域），那么这些数据都应该是从“一个数据库表”傻瓜化地抓出来数据来展示的，而不应该临时统计。即使是“实时跳动”的数据，也应该是某些系统推送过来的，而不是自己去查询统计的。
如果涉及这类系统，那么它就是分层的。在底层系统之上有至少1、2层新的框架。
而那些“竖井式思维”的做法，则什么都临时查询统计。就容易死掉了。
#4
这种读写分离，预先统计，水平分割，垂直分割，SQL优化什么的都是必须要上的了啊
#5
其实许多东西如果你仔细看，你会发现要针对去解决的那些低级程序设计的毛病都是如出一辙的。只是我们不便过多地去说而已（因为许多人的天性就是懒惰、不愿意多干）。你说你要把一个数据库分成20个数据库pool，然后再把20个数据库分别逐一地部署成“一个Master+3个Slave”的，说起来确实是高大上令人振奋，但是有几个人愿意自己动手干和维护呢？
作为设计师，有什么我们需要前思后想，然后针对“懒人们”设计出不同的优化步骤来，所以复杂的系统的建设规划总是各不相同的。目的就是让一帮比较懒的程序员也能有兴趣去跟着开发，而不是一开始就被复杂性而吓退了。
作为设计师，有什么我们需要前思后想，然后针对“懒人们”设计出不同的优化步骤来，所以复杂的系统的建设规划总是各不相同的。目的就是让一帮比较懒的程序员也能有兴趣去跟着开发，而不是一开始就被复杂性而吓退了。
#6
我也遇类似的问题，正在寻找对应办法
#7
索引才是解决知道，不过索引我感觉经常要重建
#8
建立索引,速度嗷嗷提升。
#9
使用存储过程，将统计数据写入存储过程
#10
增加缓存memcache，redis
#11
几百万数据，缓存起来，用不了多少内存。
有什么需求，用什么数据结构，一般都有O(log(n))的更新方案，查询结果小的话应该都是0ms。
有什么需求，用什么数据结构，一般都有O(log(n))的更新方案，查询结果小的话应该都是0ms。
#12
索引，优化，统计放到后台运行
#13
除了优化还是优化，不过你可以自己加锁，行锁表锁，这样就可以避免死锁之类的问题发生
#14
查询的时候加nolock
#15
上面说的重建索引通过sql server维护计划定时自动过去（其实还有数据库碎片也需要定时整理），这是从存储的角度讲的
从逻辑上讲，有些统计数据的确不适合临时查询计算，会拖垮系统，这个时候就需要仔细分析业务，优化设计了
从逻辑上讲，有些统计数据的确不适合临时查询计算，会拖垮系统，这个时候就需要仔细分析业务，优化设计了
#16
一, 每一个用户不可能每次都需要用几百万数据库做基础是吧，取相关资料
二,某些计算不需要每次都计算的就可以省点时间。
三,找到关键点，看是链接数据库读取数据时的时间多，还是计算的时间 。
二,某些计算不需要每次都计算的就可以省点时间。
三,找到关键点，看是链接数据库读取数据时的时间多，还是计算的时间 。