mysql 优化，mysql
mysql 优化（linux环境下）
方法1：添加sql日志，定位具体查询慢的语句
1，首先是在mysql配置文件中添加超时控制,在mysqld下面添加2s超时：
vi /etc/my.cnf
2，重启mysql，设置日志显示为on，查看slow_query_log可以看到显示为on了。
3，接着执行一条时间查过2s的sql，然后查看日志文件，可以看到如下的记录，接下来我们可以通过日志来进行优化了。
方法2：建立分区表。
在实际的项目开始的时候，一般不会特意去建立分区表，当项目运行一段时间后，具体定位到数据量大的表时可以考虑分区：RANGE,LIST,HASH,KEY。在实际情况当中一般是按照时间的range进行分区，下面是实际情况当中给表添加按照月的分区的sql。
alter tableWD_EnergyMeasure_His PARTITION by range(TO_DAYS(datRecTime))
(
PARTITIONp20131001 VALUES LESS THAN(TO_DAYS('2013-10-01 00:00:00')),
PARTITIONp20131101 VALUES LESS THAN(TO_DAYS('2013-11-01 00:00:00')),
PARTITIONp20131201 VALUES LESS THAN(TO_DAYS('2013-12-01 00:00:00')),
PARTITIONp20140101 VALUES LESS THAN(TO_DAYS('2014-1-01 00:00:00')),
PARTITIONp20140201 VALUES LESS THAN(TO_DAYS('2014-2-01 00:00:00')),
PARTITIONp20140301 VALUES LESS THAN(TO_DAYS('2014-3-01 00:00:00')),
PARTITIONp20140401 VALUES LESS THAN(TO_DAYS('2014-4-01 00:00:00')),
PARTITIONp20140501 VALUES LESS THAN(TO_DAYS('2014-5-01 00:00:00')),
PARTITION p20140601VALUES LESS THAN(TO_DAYS('2014-6-01 00:00:00')),
PARTITIONp20140701 VALUES LESS THAN(TO_DAYS('2014-7-01 00:00:00')),
PARTITIONp20140801 VALUES LESS THAN(TO_DAYS('2014-8-01 00:00:00')),
PARTITIONp20140901 VALUES LESS THAN(TO_DAYS('2014-9-01 00:00:00')),
PARTITIONp20141001 VALUES LESS THAN(TO_DAYS('2014-10-01 00:00:00')),
PARTITIONp20141101 VALUES LESS THAN(TO_DAYS('2014-11-01 00:00:00')),
PARTITIONp20141201 VALUES LESS THAN(TO_DAYS('2014-12-01 00:00:00'))
);
方法3：建立索引。
建立索引一般是老生常谈的技术，主键一般是索引，我们也可以在经常使用的字段上建立联合索引。
方法4：建立主从分区数据库
主数据库用于数据的插入删除修改等操作，从数据库主要用于数据的查询操作，这样可以避免在对数据进行大量修改的时候遇到比较耗时的查询导致卡死的问题。主从数据库的建立以及数据库备份的方法其他几篇文章当中都也涉及。
方法5：调整数据库参数配置
你给的信息基本没用，你没说你数据库的应用类型，以及你运营环境
配置文件基本不用改动，具体问题具体微调，他不会对数据库优化起明显作用
优化一般分一下几个：
1.存储引擎的选择。高并发，update，insert较多、切需要事务处理适用 innodb；select为主用myisam；通常所有的表会使用相同的引擎，便于维护
2.根据数据量、cpu、内存、磁盘i/o开销可以选择分表、分库、主从负载
3.最关键的就是sql和索引了，配合适当的索引，写出高效的sql是优化的基本
优化是一个调试的过程，没有1个通用的模式，要从实际情况作合理选择
select product_id, sum(stock_amount) as stock_amount, sum(stock_branch) as stock_branch from stock_details where product_id in(很多，但是一般不会超过1000) group by product_id
我不是很建议用 where product_id in(很多，但是一般不会超过1000)
这种的方式，这样速度会比较慢，如果考虑到优化一般都会用
where (表A.Product_ID=表B.Product_ID)
另：Sum()执行的时间可能比较长，建议你这个表平时做一下月结或者年结之类的处理，这种结算型的记录可以用某个字段打上标记，Sum的时候就以最后一次结算的记录往下Sum。