1.1关于数据库优化
(1)查询时，能不用* 就不用，尽量写全字段名。
(2)索引不是越多越好，每个表控制在6个索引以内。范围where条件的情况下，索引不起作用，比如where value<100
(3)大部分情况连接效率远大于子查询，但是有例外。当你对连接查询的效率都感到不能接受的时候可以试试用子查询，虽然大部分情况下你会更失望，但总有碰到惊喜的时候不是么…
(4)多用explain 和 profile分析查询语句
(5)有时候可以1条大的SQL可以分成几个小SQL顺序执行，分了吧，速度会快很多。
(6)每隔一段时间用alter table table_name engine=innodb;优化表
(7)连接时注意:小表 jion 大表的原则
(8)学会用explain 和 profile判断是什么原因使你的SQL慢
(9)查看慢查询日志，找出执行时间长的SQL进行优化
(10)尽量避免使用order by
(11)因为where子句后面的条件是执行顺序是从右到左，所以尽量把能过滤掉大部分数据的条件放在最后
1.2SQL语句优化（索引 .范式）
SELECT子句中避免使用‘*’
SQL语句用大写的
用IN来替换OR
查询语句中不要使用 *
尽量减少子查询，使用关联查询（left join,right join,inner join）替代
减少使用IN或者NOT IN ,使用exists，not exists或者关联查询语句替代
or 的查询尽量用 union或者union all 代替
合理的增加冗余的字段（减少表的联接查询）
增加中间表进行优化（这个主要是在统计报表的场景，
查询时，能不用* 就不用，尽量写全字段名。
索引不是越多越好，每个表控制在6个索引以内。范围where条件的情况下，索引不起作用，比如where value<100
大部分情况连接效率远大于子查询，但是有例外。当你对连接查询的效率都感到不能接受的时候可以试试用子查询，虽然大部分情况下你会更失望，但总有碰到惊喜的时候不是么…
多用explain 和 profile分析查询语句
有时候可以1条大的SQL可以分成几个小SQL顺序执行，分了吧，速度会快很多。
每隔一段时间用alter table table_name engine=innodb;优化表
连接时注意:小表 jion 大表的原则
学会用explain 和 profile判断是什么原因使你的SQL慢
查看慢查询日志，找出执行时间长的SQL进行优化
尽量避免使用order by
因为where子句后面的条件是执行顺序是从右到左，所以尽量把能过滤掉大部分数据的条件放在最后
三范式：
第一范式（确保每列保持原子性）最基本范式。数据库表中所有字段值都是不可分解的原子值，就满足了第一范式。
第二范式（确保表中的每列都和主键相关）在第一范式上更近一层。确保数据库表中的每一列都和主键相关，而不能只与主
键的某一部分相关，也就是说一个表中只能保存一种数据，不可以吧多种数据保存在一张表中。
第三范式：确保每列都和主键列直接相关，不是间接相关。
索引：避免对索引字段进行计算、避免索引在字段上使用not、<>、！=、避免在索引上使用IS NULL和NOT NULL、避免在索引列上出现数据类型转换、避免索引字段使用函数、避免建立索引的列出现空值
1.3 SQL注入攻击
SQL注入是一种将SQL代码添加到输入参数中，传递到服务器解析并执行的一种攻击手法。
SQL注入攻击是输入参数未经过滤，然后直接拼接到SQL语句当中解析，执行达到预想之外的一种行为，称之为SQL注入攻击。
防止SQL注入攻击
永远不要信任用户的输入，要对用户的输入进行校验，可以通过正则表达式，或限制长度，对单引号和双"-"进行转换等。
永远不要使用动态拼装SQL，可以使用参数化的SQL或者直接使用存储过程进行数据查询存取。
永远不要使用管理员权限的数据库连接，为每个应用使用单独的权限有限的数据库连接。
不要把机密信息明文存放，请加密或者hash掉密码和敏感的信息。
应用的异常信息应该给出尽可能少的提示，最好使用自定义的错误信息对原始错误信息进行包装，把异常信息存放在独立的 表中。
利用新对象PreparedStatement对象完成，先将SQL骨架发送给数据库服务器，然后再将参数单独发给服务器，并将参数中的关键字当做一个普通字符串来处理，进而起到防止SQL注入的问题