[ZT]以后谁再跟我说MySQL性能好我跟谁急……
性能测试, 数据库
http://obmem.com/?p=317
TNND，今天浪费了一天的时间在Mysql上面，先是改代码，然后是转换sqlite3数据库到mysql，然后发现原来好好的网站跑不起来了。 @。@ 然后就这么折腾了半天，基本上确定了，在select语句上，mysql的性能平均落后sqlite十倍左右，内存消耗超过sqlite则是三倍左右。
-
实际上mysql更灵活点，我的意思是：给mysql三倍的内存，那么他的表现只比sqlite慢十倍而已，如果你给他很抠门的内存？那么超时是唯一的结果。就像我一开始网站挂掉那样。
-
不过今天这么折腾的好处是：
1.对数据库的命令行操作有了全面的认识，现在我已经完全不需要phpmyadmin这种土货了
2.对数据库的优化有了全面的认识，我今天起码看了100篇以上的mysql索引优化方法，官方文档翻了个底朝天，看得吐血
-
结论是：
1.mysql太过傻X，order by怎么样都用不上index，而这应该是用膝盖想都要用index的（如果我错了，请指出，我实在是找遍网上资料，mysql官网文档都快犁了一遍了，还是没找到如何让order by用index的方法（我是指没有where语句，只有order by，至少sqlite是会去用index的，这从explain语句可以看出））
2.即使用fulltext全文索引，用where加limit搜索同样的内容，如果分页很大(例如limit 10000,1)的话，mysql的执行速度还是比sqlite慢十倍左右。
3.where加order by加limit，其中where和order by的关键字组成索引对，明显可以看出sqlite的性能提升很大，而mysql的性能则毫无多大变化。
-
有人说sqlite不开事务很悲剧，insert时间是别人的十几倍，我靠谁吃饱了撑的有事没事去insert？数据库到底是insert时间多还是select的时间多，哪怕insert时间比mysql慢一百倍，就冲它select时间比mysql快一百倍以上我就不会用mysql了。(真的有一百倍，如果用order by关键字的话，因为mysql怎么都教不会它用索引，用force index语句都不行，它就是顽固地要进行filesort，太无语了)
-
有人不信的话我可以提供数据库和测试语句，自己去折腾去
==========================
一些比较：
mysql设置：默认的large配置文件，修改sort相关的buff到16M以上
sqlite设置：无设置
数据库：verycd，表项有id，title，content，updatetime,category等，id是primary integer，数据表项有16万
索引都是三个，updatetime，(updatetime,title),(category,updatetime,title)
语句一：
SELECT title FROM verycd LIMIT 150000,1;
mysql=1 row in set (4.64 sec)
sqlite3=CPU Time: user 0.116007 sys 0.144009
语句二：
SELECT title FROM verycd ORDER BY updtime DESC LIMIT 150000,1;
mysql=1 row in set (3.97 sec)
sqlite3=CPU Time: user 0.032002 sys 0.020001
语句三：
#mysql额外做了fulltext SELECT title FROM verycd WHERE title LIKE "%4%" LIMIT 10000,1;
mysql=1 row in set (1.59 sec)
sqlite3=CPU Time: user 0.268016 sys 0.180011
语句四：
SELECT title FROM verycd WHERE title LIKE "%5%" ORDER BY updtime DESC LIMIT 10000,1;
mysql=1 row in set (1.79 sec)
sqlite3=CPU Time: user 0.184011 sys 0.020002
语句五：为mysql开个特例，用primary key做索引，它倒是用了，但是……
SELECT title FROM verycd WHERE title LIKE "%2%" ORDER BY verycdid DESC LIMIT 10000,1;
mysql=1 row in set (0.40 sec)
你好意思和sqlite3的0.02比么？
=================================
如果是我太土不会用mysql的话请千万告诉我，不然我以后就坚定地抱着mysql性能就是渣的想法了，以后除非高并发，不需要order by，也不需要limit分页的应用，否则很难相信我会去选择mysql了。
Dianso 十二月 20, 2009 于 8:23 下午
VERYCD是MYSQL数据库，我上VERYCD几年了，保存过好几次mysql繁忙的截图。
observer 十二月 20, 2009 于 8:47 下午
verycd每天号称200万IP，那个我这个不知道今天2000IP会不会有，所以不能这样比较吧，呵呵。
不过话说回来人家verycd肯定是用n台服务器，然后让n个squid或者nginx转发分流的，隶属verycd的服务器ip我就见过大概4个了。而我这个不过是一个512MB内存的虚拟主机而已。
我现在对于优化这种东西很有心得，要是让我来整verycd，性能肯定比现在要好上一大截。
observer 十二月 20, 2009 于 8:48 下午
最起码verycd的页面源代码太丑陋了，javascript满地爬，非常没有效率。
LD 十二月 20, 2009 于 9:29 下午
SQLite支持存储过程吗？ 存取控制？ 分布式解决方案？ mysql的速度不是单单的增加内存，。 另外实际应用中 insert多于select的情况也十分常见。
mysql的优点并不是速度一项， 它有很多类型的表 ISAM, MyISAM, HEAP, BDB, InnoDB … 每个表的特性不同，所以相同配置下性能会差别很大。
observer 十二月 20, 2009 于 9:46 下午
看来LD同学是mysql达人，那么请教一下我这种应用环境下应该用哪种表，怎么配置？
observer 十二月 20, 2009 于 9:49 下午
你说错了，mysql如果有优点的话，速度绝对不是其中的一项
嘛，当年Galaxy是觉得MySQL分太多类型比较麻烦，又有人说它不稳定，大数据量容易丢，就转PostgreSQL了，现在搞Perl编程是用SQLite3。
搞SQLite3时为索引还折腾过许多次，也曾经为一个SELECT只能用一个索引而郁闷。
不想MySQL竟会这么差……
Loading ...
MoeFan (萌番)
最近评论