索引优化
select * from table where char_col= int_value => select * from table where char_col= 'int_value'
select * from tabe where int_col='12abc' // 可以查出12的record
原本是VARCHAR类型,不加引号,需要加多一个转换操作,将INT转换VARCHAR,
mysql在使用varchar字段查询条件是int类型的时候会把varchar型首先转换为int型进行查询。所以就会出现查询结果与预期不符的情况。
另外如果字段类型是varchar型而查询条件使用int类型的话，查询是无法使用索引的，会进行全表的扫描。
基础
TIMESTAMP和DATETIME的不同点：
1> 两者的存储方式不一样
对于TIMESTAMP，它把客户端插入的时间从当前时区转化为UTC（世界标准时间）进行存储。查询时，将其又转化为客户端当前时区进行返回。
而对于DATETIME，不做任何改变，基本上是原样输入和输出。
2> 两者所能存储的时间范围不一样
timestamp所能存储的时间范围为：'1970-01-01 00:00:01.000000' 到 '2038-01-19 03:14:07.999999'。
datetime所能存储的时间范围为：'1000-01-01 00:00:00.000000' 到 '9999-12-31 23:59:59.999999'。
3>自动更新
Automatic Initialization and Updating只适用于TIMESTAMP，而且一张表中，最多允许一个TIMESTAMP字段采用该特性
4>timestamp为什么从1970到2038的某一时间？
MySQL的timestamp类型是4个字节，最大值是2的31次方减1，也就是2147483647，转换成北京时间就是2038-01-19 11:14:07。可以使用上面的在线的时间戳转换工具得出。
5>存储空间
在5.6.4之前，datetime存储占用8个字节，而timestamp是占用4字节；但是在5.6.4之后，由于这两个类型允许有小数部分，所以占用的存储空间和以前不同；MySQL规范规定，datetime的非小数部分需要5个字节，而不是8个字节，而timestamp的非小数部分是需要4个字节，并且这两个部分的小数部分都需要0到3个字节，具体取决于存储值的小数秒精度。
分库分表
水平分表: 订单按城市分
垂直分表: 订单按状态分
性能优化
删除大表
*凌晨删除
*innodb_file_per_table | on 共享表空间设置.删除表,会删除磁盘上的文件,如果文件过大,会阻塞很久,2步解决:硬链;删除源文件.
硬链与软链的区别?
innode和快捷方式的区别. 硬链可以防止误删,备份源文件.
硬链仅支持文件,软链支持目录和文件
numa
在运行mysql服务的服务器上，linux系统的内存numa特性是强烈建议关闭的。因为这种特性很容易引起内存泄漏的情况：即发现物理内存还有剩余，但是系统已经开始使用swap内存。
numa内存特性：比如一台机器是有2个处理器，有4个内存块。我们将1个处理器和两个内存块合起来，称为一个NUMA node，这样这个机器就会有两个NUMA node。在物理分布上，NUMA node的处理器和内存块的物理距离更小，因此访问也更快。比如这台机器会分左右两个处理器（cpu1, cpu2），在每个处理器两边放两个内存块(memory1.1, memory1.2, memory2.1,memory2.2)，这样NUMA node1的cpu1访问memory1.1和memory1.2就比访问memory2.1和memory2.2更快。所以使用NUMA的模式如果能尽量保证本node内的CPU只访问本node内的内存块，那这样的效率就是最高的。
其实由于mysql数据库服务器一般只会部署mysql一种服务在运行，而不会部署若干应用在运行。所以一般是希望mysql是独占整个服务器的资源（剔除留给操作系统运行的资源）。所以根据这种业务特性，mysql服务器上是不建议开启numa内存特性。
固态硬盘SSD和机械硬盘
1、启动快，没有电机加速旋转的过程。
2、相对固定的读取时间。由于寻址时间与数据存储位置无关，因此磁盘碎片不会影响读取时间。
3、 不用磁头，快速随机读取，读延迟极小。根据相关测试：两台电脑在同样配置的电脑下，搭载固态硬盘的笔记本从开机到出现桌面一共只用了18秒，而搭载传统硬盘的笔记本总共用了31秒，两者几乎有将近一半的差距。
避免sql注入
pre处理, sql_mode做限制
Query Cache
Query Cache有如下规则，如果数据表被更改，那么和这个数据表相关的全部Cache全部都会无效，并删除之。这里“数据表更改”包括: INSERT, UPDATE, DELETE, TRUNCATE, ALTER TABLE, DROP TABLE, or DROP DATABASE等。举个例子，如果数据表posts访问频繁，那么意味着它的很多数据会被QC缓存起来，但是每一次posts数据表的更新，无论更新是不是影响到了cache的数据，都会将全部和posts表相关的cache清除。如果你的数据表更新频繁的话，那么Query Cache将会成为系统的负担。有实验表明，糟糕时，QC会降低系统13%的处理能力。
Online DDL
黄金法则:低峰操作
copy, inplace, online ddl