在web应用中,提倡sql简单,所以在我们公司的应用中看不到jon,子查询等语句的存在,所以间接oprder by 与 limit的使用占据大多数,其实很多技巧,别人都是总结过的,仔细分析,仔细学习别人的经验才是正道.而不可浮躁,凭经验主义.

1:order by with limit

2:make sure it uses index

对于order by with limit来说,不执行扫描和排序是非常重要的,所以索引是非常重要的,index range scan执行的结果:一旦特定数量的行返回就结束.

比如 select * from sites order by date_created desc limit 10,使用索引(date_

看了下 http://andyao.javaeye.com/blog/139526
记录几个不错的优化点,偏向是myisam存储引擎

1:specific mysql functions can be tested using the built-in “benchmark” command

对于mysql表达式操作,可以使用benchmark函数进行基准测试.这是个不错的功能,目前我们的博文附属属性大量使用&操作.可以测试下相关性能.

2:Run optimize table
对于myisam表来说,经常性整理碎片,对磁盘I/O具有不错的效果,另外对我们表操作来说,一

和普通的优化建议不同,下列的整理是告诉我们那些操作行为会影响性能.

主要的理解至于存储引擎的优化

1:Thinking too small

a:最大的性能问题来至于书写的sql,schema的设计,索引策略.
b:任何一个大型系统在不同层面都有代理及缓存.
c:不要使用单个的"big box"架构.
d:尽早的进行拆分及复制
e:分离组件及应用程序
f:performance != scalability

3:choosing the wrong data types

a:尽可能使用小的数据类型
b:使用小的数据类型,索引和数据能够尽量放入内

索引选择性的重要性:

1:BTree工作原理.以前一直以为key (indexa,indexb,indexc),select * from table where indexa=1 and indexc=2 也是索引起效果的.

2:根据过滤范围,(indexa,indexb,indexc)索引未必比(indexa,indexb)好,原因在于"在复合索引里，仅仅只能保存一个range类型的查询字段，并且要放到复合索引的末尾，否则，range类型查询字段后面的索引无效"

key "cat_id" (cat_id,price)
key "cat_id_2" (cat_id,seller_id)

select * from goods where cat_id=5 a

http://xiayuanfeng.javaeye.com/blog/430852
http://hi.baidu.com/thinkinginlamp/blog/item/a352918fe70d96fd503d925e.html

比较感兴趣的是下面的分页语句
explain SELECT * FROM my_data_46 JOIN (SELECT id FROM my_data_46 WHERE `uid` = 1190363061 and status=1 order by blog_pubdate DESC LIMIT 600, 10) AS p on (p.id = my_data_46.id);

Every so often people ask me the question how should they estimate memory consumption by MySQL Server in given configuration. What is the formula they could use.

　　经常有人问我配置MySQL时该如何估算内存的消耗。那么该使用什么公式来计算呢？

　　The reasons to worry about memory usage are quite understandable. If you configure MySQL Server so it uses too small amount of memory it will likey perform suboptimally. If you however configure it so it consumes too much memory it may be c

最近部门正在做数据库读写分离,主要的好处可能有以下几点:

1:原来的读写操作都在一个库中一个表中,容易造成数据库的单点故障

2:原来每个库有256个表,单表的数据量太少,cache命中率不高,也特别浪费机器.

本次改造的重点就是读写分离,读操作使用dns轮询,对照我们简单的数据库结构和并不复杂的程序逻辑，这个改造应该是能够显著提高效果的。

前几次分别对mysina,myuser库进行了读写分离,虽然在改程序的时候也出现了一些问题,但是总体上来说还是比较顺利的,但是在切换博文数据库的时候遇到了一些问题,这

原来我们的数据库分布原则是分库分表,按照功能垂直分为gbook,cms,article表,每个库按照用户ID拆分为256个表.用户的读和写都去读一个库,采用模的机制来进行库和表的hash.我们采用专门的服务器作为数据库服务器,二颗cpu,4G的内存.

采用这种数据库架构的优势就是:

1:目前数据库的瓶颈在于链接数,当并发量大的时候,就需要扩容,比如文章库从12个库扩为24个库.这里就有几个问题,原表的ID和新表的ID是否一样,我们文章编号是通过uid+id运算而成的,扩容的时候,每个表的数据量就会减少,假如新表的ID还是自动增加,则

在mysql查询语句中,使用最多的标识符可能就是order by ，如何优化它是一个重点。

在mysql文档中,有这样一句话-MySQL可以直接使用索引来满足一个 ORDER BY 或 GROUP BY 子句而无需做额外的排序,
尽管 ORDER BY不是和索引的顺序准确匹配，索引还是可以被用到，只要不用的索引部分和所有的额外的 ORDER BY 字段在 WHERE 子句中都被包括。

以下几种情况一般不使用索引order by

1:对不同的索引键做 ORDER BY
2:在非连续的索引键部分上做 ORDER BY
3:同时使用了 ASC 和 DESC
4:用于搜索记录的索

同时在线访问量继续增大 对于1G内存的服务器明显感觉到吃力严重时甚至每天都会死机 或者时不时的服务器卡一下 这个问题曾经困扰了我半个多月MySQL使用是很具伸缩性的算法，因此你通常能用很少的内存运行或给MySQL更多的被存以得到更好的性能。

安装好mysql后，配制文件应该在/usr/local/mysql/share/mysql目录中，配制文件有几个，有my-huge.cnf my-medium.cnf my-large.cnf my-small.cnf,不同的流量的网站和不同配制的服务器环境，当然需要有不同的配制文件了。

一般的情况下，my-medium.cnf这个配制文件就能满足

在Apache, PHP, MySQL的体系架构中，MySQL对于性能的影响最大，也是关键的核心部分。对于Discuz!论坛程序也是如此，MySQL的设置是否合理优化，直接影响到论坛的速度和承载量！同时，MySQL也是优化难度最大的一个部分，不但需要理解一些MySQL专业知识，同时还需要长时间的观察统计并且根据经验进行判断，然后设置合理的参数。

下面我们了解一下MySQL优化的一些基础，MySQL的优化我分为两个部分，一是服务器物理硬件的优化；二是MySQL自身(my.cnf)的优化。

(1) 服务器硬件对MySQL性能的影响

a) 磁盘寻道能力

今天用mysql的explain分析了一条简单的sql语句，发现以前的理解基本上都是错误的.

select * from my_cms where cms_id='570e38bc01000aue' order by id asc ;
show index from my_cms; 看到id为主索引,cms_id为索引。

删除无用索引:drop index src_id on my_cms

运行 explain select * from my_cms where cms_id='570e38bc01000aue' order by id asc ;
发现结果
mysql> explain select * from `my_cms_00` where cms_id='570e38bc01000aue' order by id asc ;    

SHOW PROCESSLIST

SHOW [FULL] PROCESSLIST shows you which threads are running. You can also get this information using the mysqladmin processlist command. If you have the SUPER privilege, you can see all threads. Otherwise, you can see only your own threads. See section

mysql-explain观察sql语句效率

使用 show index，status uid blog_pubdate 做了复合索引

mysql> explain select blog_id from my_data_ec where blog_id='568da77801000fyo' ;                   
+------------+------+---------------+---------+---------+-------+------+--------------------------+
| table      | type | possible_keys | key 

今天看了一篇文章,见了数据库的分布式使用,和我们公司的数据库使用差不多,以后我也会整理一下,我们目前数据库使用的优缺点.

目前主要分布存储的方式都是按照一定的方式进行切分，主要是垂直切分（纵向）和水平切分（横向）两种方式，当然，也有两种结合的方式，达到更到的切分粒度。

1. 垂直切分（纵向）数据是数据库切分按照网站业务、产品进行切分，比如用户数据、博