MySQL进阶总结

MySQL UPDATE多表关联更新

1.MySQL 可以基于多表查询更新数据。对于多表的 UPDATE 操作需要慎重，建议在更新前，先使用 SELECT 语句查询验证更新的数据与自己期望的是否一致。

建两张表，一张表为 product 表，用来存放产品信息，其中有产品价格字段 price；另外一张表是 product_price 表。现要将 product_price 表中的价格字段 price 更新为 product 表中价格字段 price 的 80%。

一般有四种关联更新的方法：
1.使用UPDATE：UPDATE product p, product_price pp SET pp.price = p.price * 0.8 WHERE p.productid= pp.productId;
2. 通过INNER JOIN：UPDATE product p INNER JOIN product_price pp ON p.productid= pp.productid SET pp.price = p.price * 0.8;
3. 通过LEFT JOIN： UPDATE product p LEFT JOIN product_price pp ON p.productid= pp.productid SET p.isdelete = 1 WHERE pp.productid IS NULL;
4.通过子查询：UPDATE product_price pp SET price=(SELECT price*0.8 FROM product WHERE productid = pp.productid);

详细请看：http://c.biancheng.net/view/8286.html

---

MySQL如何处理无效数据值？

2.MySQL处理数据的基本原则是“垃圾进来，垃圾出去”，通俗一点说就是你传给 MySQL 什么样的数据，它就会存储什么样的数据。如果在存储数据时没有对它们进行验证，那么在把它们检索出来时得到的就不一定是你所期望的内容。

有几种 SQL 模式可以在遇到“非正常”值时抛出错误，如果你对其他数据库管理系统比较熟悉，会发现这种行为和其他的数据库管理系统很像。

下面介绍 MySQL 默认情况下如何处理非正常数据和启用各种 SQL 模式时会对数据处理产生哪些影响。

    默认情况下，MySQL 会按照以下规则来处理越界（即超出取值范围）的值和其他非正常值：
    1.对于数值列或 TIME 列，超出合法取值范围的那些值将被截断到取值范围最近的那个端点，并把结果值存储起来。
    2.对于除 TIME 列以外的其他类型列，非法值会被转换成与该类型一致的“零”值。
    3.对于字符串列（不包括 ENUM 或 SET），过长的字符串将被截断到该列的最大长度。
    4.给 ENUM 或 SET 类型列进行赋值时，需要根据列定义里给出的合法取值列表进行。如果把不是枚举成员的值赋给 ENUM 列，
    那么列的值就会变成空字符串。如果把包含非集合成员的子字符串的值赋给 SET 列，那么这些字符串会被清理，剩余的成员才会被赋值给列。

如果在执行增删改查等语句时发生了上述转换，那么 MySQL 会给出警告消息。在执行完其中的某一条语句之后，可以使用 SHOW WARNINGS 语句来查看警告消息的内容。

如果需要在插入或更新数据时执行更严格的检查，那么可以启用以下两种 SQL 模式中的一种：

  SET sql_mode = 'STRICT_ALL_TABLES' ;
SET sql_mode = 'STRICT_TRANS_TABLES';

对于支持事务的表，这两种模式都是一样的。如果发现某个值无效或缺失，那么会产生一个错误，并且语句会中止执行，并进行回滚，就像什么事都没发生过一样。

对于不支持事务的表，这两种模式有以下效果。

1) 对于这两种模式，如果在插入或修改第一个行时，发现某个值无效或缺失，那么结果会产生一个错误，语句会中止执行，就像什么事都未发生过一样。 这跟事务表的行为很相似。
 
2) 在用于插入或修改多个行的语句里，如果在第一行之后的某个行出现了错误，那么会出现某些行被修改的情况。这两种模式决定着，这条语句此时此刻是要停止执行，还是要继续执行。
   1.在 STRICT_ALL_TABLES 模式下，会抛出一个错误，并且语句会停止执行。因为受该语句影响的许多行都已被修改，所以这将会导致“部分更新”问题。
   2.在 STRICT_TRANS_TABLES 模式下，对于非事务表，MySQL 会中止语句的执行。只有这样做，才能达到事务表那样的效果。只有当第一行发生错误时，才能达到这样的效果。
   如果错误在后面的某个行上，那么就会出现某些行被修改的情况。由于对于非事务表，那些修改是无法撤销的，因此 MySQL 会继续执行该语句，以避免出现“部分更新”的问题。
   它会把所有的无效值转换为与其最接近的合法值。对于缺失的值，MySQL 会把该列设置成其数据类型的隐式默认值，

通过以下模式可以对输入的数据进行更加严格的检查：

    1.ERROR_ FOR_ DIVISION_ BY_ ZERO：在严格模式下，如果遇到以零为除数的情况，它会阻止数值进入数据库。如果不在严格模式下，则会产生一条警告消息，并插入 NULL。
2.NO_ ZERO_ DATE：在严格模式下，它会阻止“零”日期值进入数据库。
3.NO_ ZERO_ IN_ DATE：在严格模式下，它会阻止月或日部分为零的不完整日期值进入数据库。

简单来说，MySQL 的严格模式就是 MySQL 自身对数据进行的严格校验，例如格式、长度、类型等。比如一个整型字段我们写入一个字符串类型的数据，在非严格模式下 MySQL 不会报错。如果定义了 char 或 varchar 类型的字段，当写入或更新的数据超过了定义的长度也不会报错。

虽然我们会在代码中做数据校验，但一般认为非严格模式对于编程来说没有任何好处。MySQL开启严格模式从一定程序上来讲也是对我们代码的一种测试，如果我们没有开启严格模式并且在开发过程中也没有遇到错误，那么在上线或代码移植的时候将有可能出现不兼容的情况，因此在开发过程做最好开启 MySQL 的严格模式。

    可通过select @@sql_mode;命令查看当前是严格模式还是非严格模式。

例如，如果想让所有的存储引擎启用严格模式，并对“被零除”错误进行检查，那么可以像下面这样设置 SQL 模式：

    SET sql_mode ‘STRICT_ALL_TABLES, ERROR_FOR_DIVISION_BY_ZERO' ;

如果想启用严格模式，以及所有的附加限制，那么最为简单的办法是启用 TRADITIONAL 模式：

 SET sql_ mode ‘TRADITIONAL' ;

TRADITIONAL 模式的含义是“启用严格模式，当向 MySQL 数据库插入数据时，进行数据的严格校验，保证错误数据不能插入。用于事务表时，会进行事务的回滚”。

可以选择性地在某些方面弱化严格模式。如果启用了 SQL 的 ALLOW_ INVALID_ DATES 模式，那么MySQL将不会对日期部分做全面检查。相反，它只会要求月份值在 1~12 之间，而天数处于 1~31 之间，即允许像‘2000-02-30’或‘2000-06-31’这样的无效值。

另一个制止错误的办法是在 INSERT 或 UPDATE 语句里使用 IGNORE 关键字。这样那些会因无效值而导致错误的语句，将只会导致警告的出现。这些选项能让你灵活地为你的应用选择正确的有效性检查级别。

---

SQL注入基础原理

3.sql注入基础原理（超详细）：https://www.jianshu.com/p/078df7a35671

---

SQL注入是什么，如何避免SQL注入？

4.SQL 注入（SQL Injection）是发生在 Web 程序中数据库层的安全漏洞，是网站存在最多也是最简单的漏洞。主要原因是程序对用户输入数据的合法性没有判断和处理，导致攻击者可以在 Web 应用程序中事先定义好的 SQL 语句中添加额外的 SQL 语句，在管理员不知情的情况下实现非法操作，以此来实现欺骗数据库服务器执行非授权的任意查询，从而进一步获取到数据信息。

简而言之，SQL 注入就是在用户输入的字符串中加入 SQL 语句，如果在设计不良的程序中忽略了检查，那么这些注入进去的 SQL 语句就会被数据库服务器误认为是正常的 SQL 语句而运行，攻击者就可以执行计划外的命令或访问未被授权的数据。

SQL 注入已经成为互联网世界 Web 应用程序的最大风险，我们有必要从开发、测试、上线等各个环节对其进行防范。下面介绍 SQL 注入的原理及避免 SQL 注入的一些方法。

SQL注入的原理

SQL 注入的原理主要有以下 4 点：

1）恶意拼接查询:
    我们知道，SQL 语句可以查询、插入、更新和删除数据，且使用分号来分隔不同的命令。例如：
    
        SELECT * FROM users WHERE user_id = $user_id

    其中，user_id 是传入的参数，如果传入的参数值为“1234; DELETE FROM users”，那么最终的查询语句会变为：
    
        SELECT * FROM users WHERE user_id = 1234; DELETE FROM users

        如果以上语句执行，则会删除 users 表中的所有数据。
        
2）利用注释执行非法命令:
    SQL 语句中可以插入注释。例如：
    
        SELECT COUNT(*) AS 'num' FROM game_score WHERE game_id=24411 AND version=$version

    如果 version 包含了恶意的字符串'-1' OR 3 AND SLEEP(500)--，那么最终查询语句会变为：
    
        SELECT COUNT(*) AS 'num' FROM game_score WHERE game_id=24411 AND version='-1' OR 3 AND SLEEP(500)--

    以上恶意查询只是想耗尽系统资源，SLEEP(500) 将导致 SQL 语句一直运行。如果其中添加了修改、删除数据的恶意指令，那么将会造成更大的破坏。
    
3）传入非法参数:
    SQL 语句中传入的字符串参数是用单引号引起来的，如果字符串本身包含单引号而没有被处理，那么可能会篡改原本 SQL 语句的作用。 例如：
    
        SELECT * FROM user_name WHERE user_name = $user_name

    如果 user_name 传入参数值为 G'chen，那么最终的查询语句会变为：
    
        SELECT * FROM user_name WHERE user_name ='G'chen'

    一般情况下，以上语句会执行出错，这样的语句风险比较小。虽然没有语法错误，但可能会恶意产生 SQL 语句，并且以一种你不期望的方式运行。
    
4）添加额外条件:
    在 SQL 语句中添加一些额外条件，以此来改变执行行为。条件一般为真值表达式。例如：
    
        UPDATE users SET userpass='$userpass' WHERE user_id=$user_id;

     如果 user_id 被传入恶意的字符串“1234 OR TRUE”，那么最终的 SQL 语句会变为：

         UPDATE users SET userpass= '123456' WHERE user_id=1234 OR TRUE;

        这将更改所有用户的密码。

避免SQL注入

对于 SQL 注入，我们可以采取适当的预防措施来保护数据安全。下面是避免 SQL 注入的一些方法。

    1. 过滤输入内容，校验字符串
    过滤输入内容就是在数据提交到数据库之前，就把用户输入中的不合法字符剔除掉。可以使用编程语言提供的处理函数或自己的处理函数来进行过滤，还可以使用正则表达式匹配安全的字符串。
    
    如果值属于特定的类型或有具体的格式，那么在拼接 SQL 语句之前就要进行校验，验证其有效性。比如对于某个传入的值，如果可以确定是整型，则要判断它是否为整型，在浏览器端（客户端）和服务器端都需要进行验证。
    
    2. 参数化查询
    参数化查询目前被视作是预防 SQL 注入攻击最有效的方法。参数化查询是指在设计与数据库连接并访问数据时，在需要填入数值或数据的地方，使用参数（Parameter）来给值。
    
    MySQL 的参数格式是以“?”字符加上参数名称而成，如下所示：
    UPDATE myTable SET c1 = ?c1, c2 = ?c2, c3 = ?c3 WHERE c4 = ?c4
    
    在使用参数化查询的情况下，数据库服务器不会将参数的内容视为 SQL 语句的一部分来进行处理，而是在数据库完成 SQL 语句的编译之后，才套用参数运行。因此就算参数中含有破坏性的指令，也不会被数据库所运行。
    
    3. 安全测试、安全审计
    除了开发规范，还需要合适的工具来确保代码的安全。我们应该在开发过程中应对代码进行审查，在测试环节使用工具进行扫描，上线后定期扫描安全漏洞。通过多个环节的检查，一般是可以避免 SQL 注入的。
    
    有些人认为存储过程可以避免 SQL 注入，存储过程在传统行业里用得比较多，对于权限的控制是有一定用处的，但如果存储过程用到了动态查询，拼接 SQL，一样会存在安全隐患。
    
    下面是在开发过程中可以避免 SQL 注入的一些方法。
    1. 避免使用动态SQL
    避免将用户的输入数据直接放入 SQL 语句中，最好使用准备好的语句和参数化查询，这样更安全。
    2. 不要将敏感数据保留在纯文本中
    加密存储在数据库中的私有/机密数据，这样可以提供了另一级保护，以防攻击者成功地排出敏感数据。
    3. 限制数据库权限和特权
    将数据库用户的功能设置为最低要求；这将限制攻击者在设法获取访问权限时可以执行的操作。
    
    4. 避免直接向用户显示数据库错误
    攻击者可以使用这些错误消息来获取有关数据库的信息。

一些编程框架对于写出更安全的代码也有一定的帮助，因为它提供了一些处理字符串的函数和使用查询参数的方法。但同样，你仍然可以编写出不安全的 SQL 语句。所以归根到底，我们需要有良好的编码规范，并能充分利用参数化查询、字符串处理和参数校验等多种办法来保护数据库和程序的安全。

---

MySQL索引

5.索引是一种特殊的数据库结构，由数据表中的一列或多列组合而成，可以用来快速查询数据表中有某一特定值的记录。

在 MySQL 中，通常有以下两种方式访问数据库表的行数据：

1.顺序访问

    顺序访问是在表中实行全表扫描，从头到尾逐行遍历，直到在无序的行数据中找到符合条件的目标数据。

    顺序访问实现比较简单，但是当表中有大量数据的时候，效率非常低下，影响数据库的处理性能。

2，索引访问

索引访问是通过遍历索引来直接访问表中记录行的方式。

使用这种方式的前提是对表建立一个索引，在列上创建了索引之后，查找数据时可以直接根据该列上的索引找到对应记录行的位置，从而快捷地查找到数据。
索引存储了指定列数据值的指针，根据指定的排序顺序对这些指针排序。

简而言之，不使用索引，MySQL 就必须从第一条记录开始读完整个表，直到找出相关的行。
表越大，查询数据所花费的时间就越多。如果表中查询的列有一个索引，MySQL 就能快速到达一个位置去搜索数据文件，而不必查看所有数据，这样将会节省很大一部分时间。

索引的优缺点

索引有其明显的优势，也有其不可避免的缺点。

优点
索引的优点如下：

1.通过创建唯一索引可以保证数据库表中每一行数据的唯一性。
2.可以给所有的 MySQL 列类型设置索引。
3.可以大大加快数据的查询速度，这是使用索引最主要的原因。
4.在实现数据的参考完整性方面可以加速表与表之间的连接。
5.在使用分组和排序子句进行数据查询时也可以显著减少查询中分组和排序的时间

缺点
增加索引也有许多不利的方面，主要如下：

1.创建和维护索引组要耗费时间，并且随着数据量的增加所耗费的时间也会增加。
2.索引需要占磁盘空间，除了数据表占数据空间以外，每一个索引还要占一定的物理空间。如果有大量的索引，索引文件可能比数据文件更快达到最大文件尺寸。
3.当对表中的数据进行增加、删除和修改的时候，索引也要动态维护，这样就降低了数据的维护速度。

使用索引时，需要综合考虑索引的优点和缺点。

索引可以提高查询速度，但是会影响插入记录的速度。因为，向有索引的表中插入记录时，数据库系统会按照索引进行排序，这样就降低了插入记录的速度，插入大量记录时的速度影响会更加明显。这种情况下，最好的办法是先删除表中的索引，然后插入数据，插入完成后，再创建索引。

---

怎么提升索引的使用效率，设计出更高效的索引

6.索引的设计可以遵循一些已有的原则，创建索引的时候应尽量考虑符合这些原则，便于提升索引的使用效率，更高效的使用索引。

1. 选择唯一性索引

唯一性索引的值是唯一的，可以更快速的通过该索引来确定某条记录。例如，学生表中学号是具有唯一性的字段。
为该字段建立唯一性索引可以很快的确定某个学生的信息。如果使用姓名的话，可能存在同名现象，从而降低查询速度。

2. 为经常需要排序、分组和联合操作的字段建立索引

经常需要 ORDER BY、GROUP BY、DISTINCT 和 UNION 等操作的字段，排序操作会浪费很多时间。如果为其建立索引，可以有效地避免排序操作。

3. 为常作为查询条件的字段建立索引

如果某个字段经常用来做查询条件，那么该字段的查询速度会影响整个表的查询速度。因此，为这样的字段建立索引，可以提高整个表的查询速度。

        注意：常查询条件的字段不一定是所要选择的列，换句话说，最适合索引的列是出现在 WHERE 子句中的列，或连接子句中指定的列，
        而不是出现在 SELECT 关键字后的选择列表中的列。

4. 限制索引的数目

索引的数目不是“越多越好”。每个索引都需要占用磁盘空间，索引越多，需要的磁盘空间就越大。在修改表的内容时，索引必须进行更新，有时还可能需要重构。因此，索引越多，更新表的时间就越长。

如果有一个索引很少利用或从不使用，那么会不必要地减缓表的修改速度。此外，MySQL 在生成一个执行计划时，要考虑各个索引，这也要花费时间。创建多余的索引给查询优化带来了更多的工作。
索引太多，也可能会使 MySQL 选择不到所要使用的最佳索引。

5. 尽量使用数据量少的索引

如果索引的值很长，那么查询的速度会受到影响。例如，对一个 CHAR(100) 类型的字段进行全文检索需要的时间肯定要比对 CHAR(10) 类型的字段需要的时间要多。

6. 数据量小的表最好不要使用索引

由于数据较小，查询花费的时间可能比遍历索引的时间还要短，索引可能不会产生优化效果。

7. 尽量使用前缀来索引

如果索引字段的值很长，最好使用值的前缀来索引。例如，TEXT 和 BLOG 类型的字段，进行全文检索会很浪费时间。
如果只检索字段的前面的若干个字符，这样可以提高检索速度。

8. 删除不再使用或者很少使用的索引

表中的数据被大量更新，或者数据的使用方式被改变后，原有的一些索引可能不再需要。应该定期找出这些索引，将它们删除，从而减少索引对更新操作的影响。

---