1.数据库优化的必要性：
1）系统的数据都从数据库上来，数据库的吞吐量和速度一定程度决定系统的并发和响应速度；
2）系统运行与数据量成正比，数据读处理尤其是查询自然就慢；
3）Mysql数据库的数据最终在磁盘上持久化存储，读写不如Redis等这些内存数据库。
2.数据库优化的几个方面：
1）数据库设计：数据表设计遵循三范式，使用合适的数据类型，使用合适的存储引擎；
2）适当创建索引；
3）数据库扩展：数据库的分表分库，读写分离等；
4）SQL语句优化等。
3.数据表优化具体说明
3.1三范式介绍：
第一范式1NF：字段原子性
第一范式简单的说就是表中的字段是最小不可再分的，我们下边举个例子，我们看到以下一张用户表。里边的字段是不可再分的，这样就符合第一范式的原子性，可能有些朋友会疑问，这个地址还可以分成省份、城市、区/县三个字段，是的！如果是一个电商项目它需要再分，那么就不符合第一范式，所以具体还是看项目的需求，没有固定标准，在项目需求中它的设计已不可再分那么就符合第一范式！
第二范式2NF： 消除对主键的部分依赖
2NF的使用是需要满足1NF为前提，在表中添加一个业务字段，而主键不用来做业务处理，比如我们的商品表有商品id，商品id为商品的主键，但是需要创建一个商品编号列来专门处理业务，因为id太敏感，我们处理业务都是用商品编号来处理，比如展示商品时展示编号等等！
第三范式3NF：在2NF的基础上添加外键
3NF的使用必须满足2NF，要求表中的每一列只与主键直接相关而不是间接相关，（表中的每一列只能依赖于主键），比如下面的例子，订单表中有客户相关信息，在分离出客户表之后，订单表中只需要有一个用户id即可（外键），而不能有其他的客户信息。因为其他的客户信息直接关联于用户id，而不是直接与订单id直接相关。如下图所示：
三大范式只是一般设计数据库的基本理念，可以建立冗余较小、结构合理的数据库。如果有特殊情况，当然要特殊对待，数据库设计最重要的是看需求跟性能，需求>性能>表结构。所以不能一味的去追求范式建立数据库！
数据类型尽量使用可以正确存储数据的最小
优点：更小的数据类型意味着更快，占用更少的磁盘，内存、缓存和处理时间
尽量使用整型表示字符串
因为字符集和校对规则，使处理字符比整型更复杂，比如：我们使用数据库内置的datetime类型存储时间而不是字符类型，我们使用整型存储ip而不是直接将ip字符串存到数据库中
尽可能使用not null
这个值是很烦人的，建字段时请尽量指定是否非空，NULL使得索引，统计，比较都变得更复杂，而且索引尽量不要创建到可以为null的字段上
字符串类型
VARCHAR是可变长字符串
比定长字符串（CHAR）更节省空间，仅使用必要的空间另外VARCHAR需要额外字节记录字符串长度（不同情况需要字节数不同）
CHAR类型是定长字符串
开发中基本很少用(一些公司甚至基本上不考虑这种类型了)，注意：字符串长度定义不是字节数，是字符数
日期和时间类型
datetime
使用8字节存储空间，保存从1001年到9999年的秒数。与时区无关，默认情况下,Mysql以一种可排序的格式显示它的值，例如：“2018-10-14 22：30：08”
timestamp
只使用4字节存储，保存1970年1月1日午夜以来的秒数，依赖于系统时区，和UNIX时间戳相同，转换函数分别为FROM_UNIXTIME()和UNIX_TIMESTAMP()，可以设置根据当前时间戳更新，比如我们熟悉的update_time字段
整数类型
UNSIGNED
属性表示不允许负值，可以使得正数的上限提高一倍，比如tinyint+unsigned可以使原本的-128127的范围变为0255
tinyint
我们一般用它存储状态值而不要用int，如果是Boolean类型，那么tinyint(1)当值为1和0时，查询结果自动转为true和false，条件参数相应的也可以直接传入true和false即可
INT(11)
不会限制值的范围，只是规定了一些客户端工具用来显示的字符的个数，所以对于存储和计算来说INT(11)和INT(1)相同
IP地址
实际上是32位无符号整数，用INT存储，Mysql提供转换函数为INET_ATON()和INET_NTOA()
小数
decimal不会损失精度，存储空间会随数据的增大而增大。double占用固定空间，较大数的存储会损失精度，通常存金额用decimal(11,2),这表示整数部分和小数部分分别为9位和2位注意！，当然可以根据具体的金额大小选择长度，注意这时候对应的java中用BigDecimal类来处理运算时要仔细，因为加减法和比较跟平常不一样
