mysql优化笔记

(^o^)/~完美

l  表设计上的一些技巧：
l  在一个数据库中，可以不同的表使用不同的存储引擎，而不是一个数据库的表就只能使用一种引擎！！
当建表时，要考虑好“如何选择好表的mysql存储引擎?”的问题！
应该从项目实际出发结合各种引擎的特性来抉择：
1.      如果表中大量地以select或insert为主，例如论坛的评论表和回复表，那么就使用MYISAM存储引擎；如果是以select,update和delete为主，就是用INNODB存储引擎。
2.      如果表对事物安全要求高的话，例如订单表和财务表等，就应该使用INNODB；
l  一下是各种主流的mysql存储引擎的特性：

建立表的时候选择存储引擎的语法：(就是加一句)
Create tabletable_name(id int primary key,name varchar(50)) engine= innodb;
Create tabletable_name(id int primary key,name varchar(50)) engine= myisam;
Create tabletable_name(id int primary key,name varchar(50)) engine= memory;
l  选择MYISAM存储引擎的时候，要注意：定时进行碎片整理！！
项目经验：一个应用往往在刚开始的时候还能跑得很快，但是随着时间的推移（一年左右吧），我们会发现她突然变慢了，而且是慢的越来越离谱----这种情况出现的原因往往是：表中的数据积累量过大，应该考虑清理历史数据了；但是如果你发现：我每一次都有delete数据啊？！！ 此时，就应该想到数据库要碎片整理！！在MYISAM引擎的表中，一定要定时进行碎片整理，否则你delete的数据是永远无法删除的！！
语句是：optimize tabletable_name;就一句话就能令速度飞起来！！
l  对于drop table table_name;如果只进行到一半就关掉的话，再次启动时，mysql会将残缺的部分当垃圾给清理掉！！
l  什么时候相当于commit？DML过后即使没有输入命令commit，但是后面的其他DML命令执行后也相当于前面的都commit了，这些都可以冲备份文件中看到的。
l  在mysql中，表的分割不是数据库对象的一种，别和分区表弄混了，而是我们程序员根据业务要求而对表进行的设计方式（或者说是思想）而已（例如我们按照省份分区的话，就应该创建34张表对应每个省份，这就是水平分割；将一张字段很多的表的字段拆分成多个部分再分别成表，而各表之间以外键进行约束，这样就是垂直分割）。
l  我们在设计表时，如果要水平分割的话，要考虑清楚按照什么标准分区，这个标准往往要根据具体的业务需求来确定，例如按照时间分还是按照省份分。
l  我们在设计表时，会遇到一些表的字段非常多而且某些字段存储的数据（例如存储一篇文章）都是挺大的又不是经常要查询的话，这就要考虑垂直分割这张表了.否则我们的查询就会因为同一张表中的这些字段过大而无奈地扫描过多没用的数据，这样的话，还不如将之瘦身--垂直分割。
l  tinyint(3),int(6),这些数据类型的意思是：当数值的位数不够括号中的指定的位数时，就会用0进行填充；如果满足了，则不填充了。如int(5)类型的字段值是4的话，select出来的数据就是00004；int(5)类型的字段值是4445644的话，select出来的数据就是4445644；
l  字段数据类型的选择：保小不报大 。能够使用小的数据类型就别使用大的，例如：商赛中注册人数不超过20000人的话，就没必要讲id设置为int，因为int是占四个字节的，最大值是 2147483647，这样子就会每条记录都占据着很多没用到的空间，就会使查询的数据块大大增多和IO大大增加！！
l  如果在项目开发的过程中遇上很变态的要求，例如字段数据长度超过了bigint的范围，但是有要求必须是整形的，那么就得使用varchar类型存放。如果还要运算的话，也只能先将之select出来切割成多个部分后再分别运算再合并成正确的结果返回好了。
l  我们的一些图片和视频资源，常规的做法是在apache或者tomcat下新建个文件夹存放，然后再将路径存放在DB中，其实这在高并发中是使不得的，因为每个用户点击视频时，都会占据太多的带宽了，这样的话大家就不用访问了。别人大型网站都是单独一台带宽超大的超强服务器来存放的，而在页面加载时在通过路径将之链接过来的！！！！例如优酷和阿里巴巴。
l  虽然mysql的max_connections（可以修改）是在2000左右，就是在高并发环境下最多能支撑2000人同时访问数据库。但是现在如果项目的页面静态化和缓存技术使用好的话，就可以将令网站支撑10万人都不成问题，因为有了缓存，就不需要频繁访问数据库了，这样数据库就不会崩溃。如果访问量实在过于高并发的话，就得考虑使用多个数据库，例如使用读写分离等技术了。
l