系统数据量大，页面访问缓慢，求解决方案···················
首先谢谢各位进入该帖····
哈哈·········
然后说下偶的问题哈···········
第一、web端是php写的，数据库是mysql5.1以上····
第二、根据用户数的不同，数据量非常的大，数据库已经采用了按天分区，即每天一个分区，这样查询的时候能快一些,后台插入数据库的优化工作基本就那样了，现在主要是web端查询显示问题····
第三、查询的显示形式如下：
第四、对web的技术不是很了解，采用Ajax与php结合，能不能改变我现有系统的状况呢？如果能，该怎么弄呢？
第五、如果Ajax不行的话，那就要采取其他方式，比如自己写控件，让其数据在控件中显示，达到数据缓存的效果，那么写控件的话是才用java 的applet呢？还是用c++的atl呢？ 写控件的话能达到web性能优化的效果吗？
第六、55555555555，疑问比较多，求高人一起讨论和解答············
[解决办法]
学习
[解决办法]
第一,做分页是错误的.
原因:一个100人的公司,每天的记录会高达百万,哪个网管\公安机关会分页去浏览.
此功能在此应用中无效.
第二,应提供excel文件下载,在本地对数据进一步处理才是正确的.
第三,对于网管的正常工作来讲,搜索是最关键的,所有注意力都应该集中到这里.
[解决办法]
精简数据~
[解决办法]
单纯且无意义的列表方式~~~~~~~~~~~~~~
[解决办法]
显示最近1000条足够了
[解决办法]
学习。
[解决办法]
帮顶
[解决办法]
路过 可以用分页啊 但是数据说没有人会去一页一页找的
做一个便利的查询 功能。
[解决办法]
是系统数据量大，使页面访问缓慢
还是访问量大，使页面访问缓慢
前者纯粹是因为数据库设计问题、sql语句编写问题造成的，建议使用数据库索引、带where的sql语句解决
后者就要具体问题具体分析了
[解决办法]
帮顶.
数据量大导致的查询问题.如果已经在设计方面进行了优化.那就是说是SQL的问题..
另.你猫头像挺忧郁的...
[解决办法]
确定你的SQL没有出现像什么not in 啊,不等于啊什么的.
根据你贴的图猜测,一天86.4K分钟.一分钟不到10条.
就算白天高些,百万级的MYSQL还是能拖着跑的.
或者如果不介意的话,能否把你主要的查询SQL丢出来.如果有关机密就算了.
[解决办法]
建立索引
[解决办法]
后台数据库的优化工作指那些？查询绑定？缓存？读写分离？
[解决办法]
你这个页面不复杂，显示应该不存在问题，出问题应该是在取数据这一块，注意使用缓存技术
[解决办法]
AJAX貌似可以解决你的问题，但是你得告诉你的客户，他们必须容忍第一次打开画面是的慢。
我上个项目就是这样解决的，百万级的数据量，初次检索会很慢。
[解决办法]
另外，我不推荐Ajax，不是很好弄，比较麻烦。
我推荐小鸭子多增加一些查询条件，
帮助客户更好的定位他需要的数据，
重要提示：如果技术上不可能有什么大的突破的话，可以尝试走业务路线，曲线救国。
[解决办法]
推荐Ajax.数据缓存.其实我觉得asp可以解决速度问题你用php，就不知道哦。可以去了解一下，其他大型网站是什么搞的。BAIDU搜一下
[解决办法]
分几台机器，几个数据库。。。。。。。。
比如http的log一个库（或者根据ip段分多个库），email的分一个（或者和新闻组、blog等量不大的放在一起）。
对于php我不熟。
从java方面考虑，每个项目（左边的树节点）的存储，都用一个独立数据源（DataSource),数据库分多个，放在多台服务器上。
------解决方案--------------------
换个大点数据库,连接慢,速度快
[解决办法]
数据量如果大的话别用mysql了
[解决办法]
什么东西，看的不太懂
[解决办法]
换数据库，修改代码。
[解决办法]
涉及到数据库的优化,如果根据需要建了索引还不能解决，加上缓存试试
[解决办法]
我要说的两点上面有人给你建议过。
“取前边1000条记录就够，办正事的用户大多没心思翻页到几百页之后去”，我比较赞同。你看google或者百度的查询结果，只能翻页到1000条记录左右，就不能往后翻了。因此你没必要查询出几十万条记录再执行分页功能，而应该为查询增加“条件”功能，例如有一个“开始审计时间”条件，用户可以给出条件来缩小查询范围。
另外，如果你的数据库没有索引，但是查询时又用到了“order by”，也会很慢。
上面的其它方法，你可以去尝试，包括你所使用的按日分区的做法，我觉得关系不是最大的。
[解决办法]
sql 优化确实有很多方面需要学习~
[解决办法]
从数据库端进行优化吧，并进一步你的需求：
1）真的有必要列出所有数据吗？有人看吗？
2）是不是应该根据ip进行搜索，进行分组，也许更应该关心某个ip的访问次数，而不是所有访问的地址
3）搜索相关字段建立索引
[解决办法]
我要说的两点上面有人给你建议过。
“取前边1000条记录就够，办正事的用户大多没心思翻页到几百页之后去”，我比较赞同。你看google或者百度的查询结果，只能翻页到1000条记录左右，就不能往后翻了。因此你没必要查询出几十万条记录再执行分页功能，而应该为查询增加“条件”功能，例如有一个“开始审计时间”条件，用户可以给出条件来缩小查询范围。
另外，如果你的数据库没有索引，但是查询时又用到了“order by”，也会很慢。
上面的其它方法，你可以去尝试，包括你所使用的按日分区的做法，我觉得关系不是最大的。
[解决办法]
我认为是
数据库设计前期有没有认真去设计。
SQL语句没有考虑周全，没有研究过mysql，我用的是MS SQL，
比如说可以把索引建立在日期上这样会快很多，而且不知道MYSQL有没有TOP这样的语句，有的话用TOP也不错。
[解决办法]
我现在在做的系统，数据量也是相当的大。
我们的解决方法是：
1。数据库建索引
2。查询页面中，如时间条件是必选的。默认为当天。另外数据还做了隔离。如下级不能看一级。。。。。。
[解决办法]
数据库是mysql???处理大数据量的,据我所知 mysql速度是超慢的,第2 可以用存储过程进行对数据库的调用.
1,执行速度快,存储过程在创建时就经过了语法检查和性能优化,在经过第一次调用之后,就驻留在内存中,不必再经过编译和优化,所以执行速度快.
2,模块化的程序设计.
3,减少网络通信量.
4,保证系统的安全性.
[解决办法]
关于大数据量的优化的几个思路：
1.建立索引，建立索引可以很大幅度地提高数据访问的速度。一般的原则是，Where条件中(index1 < 200) and (index2 > 100) and (index3 = 10)；以index1,index2,index3的方式在数据库中创建索引。同时，在WHERE条件中尽量不要有计算式，如(substr(index1,2,3) = 'aaa')。
2.这种分页查询非常慢。不过对于Mysql来说有个非常快的查询方法就是：LIMIT语法。每个分页中的数据就是使用LIMIT语法查询出来，这样从MYSQL服务端发出来的数据就非常的少。对你的查询来说，就是2399分之1的数据量。
[解决办法]
如果数据量大，不建议用实时查询，用历史表，历史查询记录来做
然后，有些即时数据，最好是用内存来做，降低数据库压力
[解决办法]
看你那才几万条数据（一天吧），不是数据量的问题
建议，显示最新10页左右，而且用存储过程分页，点一页取一页数据
做一个好的查询（统计），然后就是如何显示到页面的问题
[解决办法]
列出最近的1000条可以了.
要想更多的数据,用高级查询去查询
输入IP地址 网页名称,时间段等等.
分析用户查询出来后是想做什么?下一步要进行什么操作.
总之,仅是简单的将几万条数据列出来是没有任何意义的.
[解决办法]
数据本地化
[解决办法]
一次查询的数据量太大
应该一次取100-200条，这样就没问题了。
数据库调优可以调整索引，修改数据库引擎和参数配置。
[解决办法]
顶，应该只显示最新的若干条记录就可以了，这样会快很多的，哈哈
------解决方案--------------------
数据访问缓慢，我柑橘应从基本入手：数据库．
一
１建立数据库索引．
２做连接池
如果以上两点存在,那应该考虑程序．
二
程序上包括（代码的逻辑,sql语句的效率等等）．代码的拖沓,或者sql语句的低效率将会导致数据加载过多，或者查询缓慢甚至死连接．
三缓存页面：
将页面数据缓存到内存中（如oscache或者其他框架），
不经常查询的数据和信息（如你左侧的导航分类,一般是固定不便甚至是很少改变．就应当放入缓存中．减少对数据库的连接操作．）．
查询的数据如果不经常改动（如右侧信息数据）也应该放到缓存中．
五：静态页面的生成．
不用多说了，采用静态页面减少数据访问．
五
有必要错页面数据压缩,如gzip等．减少每必要的网络输出．
如果针对你贴图的这个信息来看，访问过慢．或许：１数据量过大，２大多是从数据库查询 ３检查分页代码 ４应当做必要的优化处理．
[解决办法]
要精减流程。
[解决办法]
哇，高人都进来了，膜拜一下。。。。
[解决办法]
[color=#FF0000]如果数据库的查询固定了。那么就生成静态页吧。这样会快一些。[/color]
[解决办法]
MARK
[解决办法]
如果只是针对日志的查看、跟踪和审计，只有记录追加，使用文本文件就可以了，没必要使用数据库。文本文件占用资源小，查看查找、容易，处理也容易。根据日志大小分成没天、或每小时、或者每月一个文件就可以了。如要防更改，定时可到光盘上就得了。
另外，使用网格显示那么多的记录没用，没人看，除非提供查找工具。谁会浏览google的查询记录100页以后？我曾找到20页就烦了不再找。
[解决办法]
如果是因为后台数据量大造成查询速度慢的话，讨论前台如何优化就意义不大了，楼主应该把优化的重点放在后台系统上。即解决大数据量查询速度慢的问题。
从楼主提供的资料分析，这是对历史日志记录的查询，历史日志数据的特点是插入后就不会再改变，属于相对静止状态，对于静态数据的查询可以通过建立完备的索引来提高查询速度。就本人的经验来说，从几万条记录里面搜索出15条记录，应该是可以做到非常快的速度，关键是针对查询条件做对索引。所以要提高查询速度，应从分析客户端的查询条件入手，建议楼主把表结构和查询SQL语句公布出来供大家分析。
[解决办法]
无论什么类型的数据库……，其实际部署与开发调试是有本质区别的~
比如标准开发模式只是提供一个基本功能，满足基本使用~
而专业、服务器模式就直接涉及到数据库的利用方向和利用律：直接影响到吞吐和速度~
……估计你的mysql安装模式不对~
ajax主要是解决“视图”交互的：只是减小了框架传输，中间的数据运输效率是相同的！只是个灵活性问题~
根本上解决不了数据吞吐问题，它倡导的是无刷新而已~
[解决办法]
只有35985条数据,这数据量根本就不能称作数据量大! 我们现在做的系统,每天的数据量4000万左右. 有一些作法可以大家讨论一下.
1.将数据分级.
一级(基础数据)-->二级-->三级
[解决办法]
只有35985条数据,这数据量根本就不能称作数据量大! 我们现在做的系统,每天的数据量4000万左右. 有一些作法可以大家讨论一下.
1.将数据分级, 二级或三级数据是为出报表时定制的.
一级(基础数据)-->二级-->三级
2.在分页时切记不能一次将数据全部查出放到内存中.
用两个SQL语句,一个是负责统计符合条件的数据共有多少条的,这样就可以算出有多少页, 另外一个SQL用limit取出当前页的数据
3.可以用索引
4.可以考虑用ajax,这对于网速慢的客页确实能起到较好的效果
[解决办法]
就3万条数据 就跑不动,应该是索引的问题.
[解决办法]
ajax 只能改善用户体验,
会增加系统负担的
[解决办法]
如果慢 就不要去时时 count ,可以把 count 结构放在apc缓存里.
也可以学学uchome,
[解决办法]
看了一轮，大概说说。。
1、mysql5.1.3 以上版本的表分区功能 现在应该还处在一个 测试阶段，实际上的应用性能 似乎还有比
较大的争议。我用 1kw 的记录在自己虚拟机上跑跟没分区差不了多少。。如果那个分区的key 设置不当，
可能会更慢。例如我是按 时间分区，最后我却按某个id 或者IP去查找！
(如果你说的是自己按日分表，那这点忽略吧。。)
2、我不太清楚你那个 30000 多条数据是根据什么条件搜索出来的，如果表里面本来就已经有 数百万的数据，
突然搞个 "select count(*) .." 去检索 估计够呛！一般来说对于 要做到分表的结构 我们现在是不提供
象共有多少页，共多少条之类的显示的，大不了如楼上大家讲的，读他1000条 出来 再基于这1000条做一个
分页就算了。。
3、还是如楼上几为兄弟所讲，这类系统的重点应该放在搜索而不是列表，没有人会翻那么多页的，
参考你的截图，如果是搜索的话 有可能按照 IP 或者 时间搜索 为主，如果是按照 时间搜索
那么你现在按日分区的做法 应该没什么大问题，如果是以IP搜索为主，那你应该考虑自己通过IO 或者
其他方面做一些 辅助性的 索引，以其在真正对 "主库搜索前先做好定位！" (这个定位可能包括 你所讲的
时间，又或者是库里面 主键 等~！)
---------------------------------------------
大概就这些吧，随便说说~~
------解决方案--------------------
哦。。 忘记了 还有一点，
ajax 按照我的理解，只是一个数据更新时的呈现方式 而已。。
最终读库操作的还是PHP，用与不用 关系应该不大，看你自己的用户体验需求而已。
试想一下，如果 用PHP 1秒内从库里的 数百万条记录 中读出了三条， 在通过AJAX把这三条数据呈现，
AJAX会慢吗？
当然，如果你是 一次把 数10条数据 塞进AJAX里面 然后用分页也通过AJAX处理，那用户第一次读的时候将会
非常 非常 非常之慢。。
这速度限制 更主要的方面 是由 IE的 解释执行机制决定的，
你试下 一次在IE上打印 2000条记录的列表就知道了 呵呵
mysql 几秒就读完了， ie 可能还要等上 数十秒才完成 列印出来！
