mysql 高级

Sql优化：

1.SELECT语句中避免使用 *，

尽量根据业务需求按字段进行查询

举例：如果表中有个字段用的是clob或者是blob这种大数据字段的话，

他们的查询应该根据业务需要来进行指定字段的查询，切记勿直接用*

2.删除重复记录(oracle)：

最高效的删除重复记录方法 ( 因为使用了ROWID)例子：

DELETE  FROM  EMP E  WHERE  E.ROWID > (SELECT MIN(X.ROWID)

FROM  EMP X  WHERE  X.EMP_NO = E.EMP_NO);

3. 用>=替换>

如一个表有100万记录，一个数值型字段A，

A=0时，有30万条；

A=1时，有30万条；

A=2时，有39万条；

A=3时，有1万记录。

那么执行 A>2 与 A>=3 的效果就有很大的区别了，因为 A>2 时，

ORACLE会先找出为2的记录索引再进行比较，

而A>=3时ORACLE则直接找到=3的记录索引。

4.尽量多使用COMMIT

如对大数据量的分段批量提交

5. 用NOT EXISTS 或（外连接+判断为空）方案 替换 NOT IN操作符

此操作是强列推荐不使用的，因为它不能应用表的索引。

推荐方案：用NOT EXISTS 或（外连接+判断为空）方案代替

6.LIKE操作符(大数据的全文检索使用luncene)(solr)

因为使用like不当，会导致性能问题，原因是like在左右两边都有%的时候，不会使用索引。

如LIKE '%5400%' 这种查询不会引用索引，

而LIKE 'X5400%' 则会引用范围索引。

一个实际例子：

查询营业编号 YY_BH LIKE '%5400%' 这个条件会产生全表扫描，

如果改成         YY_BH LIKE 'X5400%' OR YY_BH LIKE 'B5400%'

则会利用    YY_BH  的索引进行两个范围的查询，性能肯定大大提高。

7.避免在索引列上使用计算和函数,这样索引就不能使用

举例:

低效：

SELECT … FROM  DEPT  WHERE SAL * 12 > 25000;

高效:

SELECT … FROM DEPT WHERE SAL > 25000/12;

8.用UNION-ALL 替换UNION，

因为UNION-ALL不会过滤重复数据而且不会自动排序，

所执行效率要快于UNION。

9. （优化,重点,3个方面 a.缓存 b.分段批量 c.存储过程）减少访问数据库的次数

举例:如果批量删除多条数据，可以用  delete  from tableName where id in (1,2,3)

而不要用多条delete语句进行删除

10.用TRUNCATE替代DELETE

TRUNCATE不记录日志，DELETE记录日志，所以TRUNCATE要快于DELETE

但是一旦用TRUNCATE进行删除就不能进行恢复,TRUNCATE是删除整张表的数据

不能加where条件。

==================================================================

mysql,sqlserver中如果

id为自增类型，那么如果用TRUNCATE删除，则id字段再插入数据时从1开始，

如果delete删除的话，则从删除之前的id的值继续增长。

(1)、explain出来的各种item的意义；

select_type

表示查询中每个select子句的类型

type

表示MySQL在表中找到所需行的方式，又称“访问类型”

possible_keys

指出MySQL能使用哪个索引在表中找到行，查询涉及到的字段上若存在索引，则该索引将被列出，但不一定被查询使用

key

显示MySQL在查询中实际使用的索引，若没有使用索引，显示为NULL

key_len

表示索引中使用的字节数，可通过该列计算查询中使用的索引的长度

ref

表示上述表的连接匹配条件，即哪些列或常量被用于查找索引列上的值

Extra

包含不适合在其他列中显示但十分重要的额外信息

(2)、profile的意义以及使用场景；

查询到 SQL 会执行多少时间, 并看出 CPU/Memory 使用量, 执行过程中 Systemlock, Table lock 花多少时间等等

2、防sql注入

针对防sql注入，我们通常是这样做的：

首先在前台页面对用户输入信息进行js验证，对一些特殊字符进行屏蔽，

比如：or ,单引号，--，= ，还有就是限制用户名输入的长度，我们一般将其限制在6---13位。另外，对于用户的敏感信息我们进行Md5加密，还有，为了增加用户体验度和用户友好度，为了不使用户看到一些详细的异常信息我们会进行错误信息页面的定制，像404,500错误。另一个我层面讲，这样做也是为了保护我们的一些重要信息。此外，我们会给特定的人分配定定的权限，而不是给其分配管理员权限！

sql注入

所谓SQL注入，就是通过一些含有特殊字符的sql语句发送到服务器欺骗服务器并进行攻击。（特殊字符：or, 单引号，--，空格）

Sql注入的防护

1.永远不要信任用户的输入。对用户的输入进行校验，可以通过正则表达式（js正则），或限制长度；对单引号和双"-"进行转换等。

2.永远不要使用动态拼装sql，使用参数化的sql。（永远不要使用+号拼接sql字符串，而是使用？传参的方式进行）

3.不要给用户太高的权限而根据需求进行赋权

4.对敏感信息进行加密 如md5(单向加密不可逆转)。

5.自定义错误页面。目的是为了不把我们的程序的bug暴露在别有用心的人的面前。而去不会让用户看到报错的页面，也提高了用户的体验度。

SQL注入防范

使用参数化的过滤性语句

　　要防御SQL注入，用户的输入就绝对不能直接被嵌入到SQL语句中。恰恰相反，用户的输入必须进行过滤，或者使用参数化的语句。参数化的语句使用参数而不是将用户输入嵌入到语句中。在多数情况中，SQL语句就得以修正。然后，用户输入就被限于一个参数。

输入验证

　　检查用户输入的合法性，确信输入的内容只包含合法的数据。数据检查应当在客户端和服务器端都执行之所以要执行服务器端验证，是为了弥补客户端验证机制脆弱的安全性。

　　在客户端，攻击者完全有可能获得网页的源代码，修改验证合法性的脚本（或者直接删除脚本），然后将非法内容通过修改后的表单提交给服务器。因此，要保证验证操作确实已经执行，唯一的办法就是在服务器端也执行验证。你可以使用许多内建的验证对象，例如Regular Expression Validator，它们能够自动生成验证用的客户端脚本，当然你也可以插入服务器端的方法调用。如果找不到现成的验证对象，你可以通过Custom Validator自己创建一个。

错误消息处理

　　防范SQL注入，还要避免出现一些详细的错误消息，因为黑客们可以利用这些消息。要使用一种标准的输入确认机制来验证所有的输入数据的长度、类型、语句、企业规则等。

加密处理

将用户登录名称、密码等数据加密保存。加密用户输入的数据，然后再将它与数据库中保存的数据比较，这相当于对用户输入的数据进行了“消毒”处理，用户输入的数据不再对数据库有任何特殊的意义，从而也就防止了攻击者注入SQL命令。

存储过程来执行所有的查询

　　SQL参数的传递方式将防止攻击者利用单引号和连字符实施攻击。此外，它还使得数据库权限可以限制到只允许特定的存储过程执行，所有的用户输入必须遵从被调用的存储过程的安全上下文，这样就很难再发生注入式攻击了。

使用专业的漏洞扫描工具

　　攻击者们目前正在自动搜索攻击目标并实施攻击，其技术甚至可以轻易地被应用于其它的Web架构中的漏洞。企业应当投资于一些专业的漏洞扫描工具，如大名鼎鼎的Acunetix的Web漏洞扫描程序等。一个完善的漏洞扫描程序不同于网络扫描程序，它专门查找网站上的SQL注入式漏洞。最新的漏洞扫描程序可以查找最新发现的漏洞。

确保数据库安全

　　锁定你的数据库的安全，只给访问数据库的web应用功能所需的最低的权限，撤销不必要的公共许可，使用强大的加密技术来保护敏感数据并维护审查跟踪。如果web应用不需要访问某些表，那么确认它没有访问这些表的权限。如果web应用只需要只读的权限，那么就禁止它对此表的 drop 、insert、update、delete 的权限，并确保数据库打了最新补丁。

安全审评

在部署应用系统前，始终要做安全审评。建立一个正式的安全过程，并且每次做更新时，要对所有的编码做审评。开发队伍在正式上线前会做很详细的安全审评，然后在几周或几个月之后他们做一些很小的更新时，他们会跳过安全审评这关， “就是一个小小的更新，我们以后再做编码审评好了”。请始终坚持做安全审评。