如何使用PDO查询Mysql来避免SQL注入风险

我把问题和赞同最多的答题翻译了下来。提问：如果用户的输入能直接插入到SQL语句中，那么这个应用就易收到SQL注入的攻击，举个例子：$unsafe_variable = $_POST['user_input']; mysqli_query("INSERT INTO table (column) VALUES ('" $unsafe_variable "')");用户可以输入诸如 ： value'); DROP TABLE table;-- ,SQL语句就变成这样了:INSERT INTO table (column) VALUES('value'); DROP TABLE table;--')(译者注：这样做的结果就是把table表给删掉了) 我们可以做什么去阻止这种情况呢？回答：使用prepared statements（预处理语句）和参数化的查询。这些SQL语句被发送到数据库服务器，它的参数全都会被单独解析。使用这种方式，攻击者想注入恶意的SQL是不可能的。要实现这个主要有两种方式：1 使用 PDO：$stmt = $pdo->prepare('SELECT FROM employees WHERE name = :name'); $stmt->execute(array(':name' => $name)); foreach ($stmt as $row) { // do something with $row }2 使用 Mysqli：$stmt = $dbConnection->prepare('SELECT FROM employees WHERE name = '); $stmt->bind_param('s', $name); $stmt->execute(); $result = $stmt->get_result(); while ($row = $result->fetch_assoc()) { // do something with $row }PDO需要注意的是使用PDO去访问MySQL数据库时，真正的prepared statements默认情况下是不使用的。为了解决这个问题，你需要禁用模拟的prepared statements。下面是使用PDO创建一个连接的例子：$dbConnection = new PDO('mysql:dbname=dbtest;host=127001;charset=utf8', 'user', 'pass'); $dbConnection->setAttribute(PDO::ATTR_EMULATE_PREPARES, false); $dbConnection->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);上面的例子中，错误报告模式并不是强制和必须的，但建议你还是添加它。通过这种方式，脚本在出问题的时候不会被一个致命错误终止，而是抛出PDO Exceptions，这就给了开发者机会去捕获这个错误。然而第一行的 setAttribute() 是强制性的，它使得PDO禁用模拟的prepared statements并使用真正的prepared statements。这可以确保这些语句和值在被发送到MySQL服务器之前不会被PHP解析（这使得攻击者没有注入恶意SQL的机会）。尽管你可以使用可选的构造函数参数去设置 charset ，但重点需要注意的是小于536的PHP版本，DSN(Data Source Name)是默认忽略 charset 参数的。说明当你传一个SQL语句做预处理时会发生什么？它被数据库服务器解析和编译了。通过指定参数（通过之前例子中的 或者像 :name 这样的命名式参数）你告诉数据库引擎你是想过滤它。接着当你调用 execute() 函数时，prepared statements会和你刚才指定的参数的值结合。在此重要的是，参数的值是和编译过的语句结合，而非一个SQL字符串。SQL注入就是当创建被发送到数据库的SQL语句时，通过欺骗的手段让脚本去引入恶意的字符串。因此当你使用单独的参数发送真实正确的SQL时，你就限制了被某些不是你真实意图的事情而搞挂掉的风险。使用prepared statements 传递的任何参数都会被当做字符串对待（不过数据库引擎可能会做一些优化，这些参数最终也可能变成numbers）（译者注：意思就是把参数当做一个字符串而不会去做额外的行为）。比如在上面的例子中，如果 $name 变量的值是 'Sarah'; DELETE FROM employees ，产生的结果是会去搜索"'Sarah'; DELETE FROM employees"这一整个字符串，最终的结果你也就不会面对的是一张空表了。使用prepared statements的另一个好处是，如果你在同一session中再次执行相同的语句，也就不会被再次解析和编译，这样你就获得一些速度上的提升。

MySQL 在崩溃恢复时，会遍历打开所有 ibd 文件的 header page 验证数据字典的准确性，如果 MySQL 中包含了大量表，这个校验过程就会比较耗时。 MySQL 下崩溃恢复确实和表数量有关，表总数越大，崩溃恢复时间越长。另外磁盘 IOPS 也会影响崩溃恢复时间，像这里开发库的 HDD IOPS 较低，因此面对大量的表空间，校验速度就非常缓慢。另外一个发现，MySQL 8 下正常启用时居然也会进行表空间校验，而故障恢复时则会额外再进行一次表空间校验，等于校验了 2 遍。不过 MySQL 80 里多了一个特性，即表数量超过 5W 时，会启用多线程扫描，加快表空间校验过程。

如何跳过校验MySQL 57 下有方法可以跳过崩溃恢复时的表空间校验过程嘛？查阅了资料，方法主要有两种：

1 配置 innodb_force_recovery可以使 srv_force_recovery != 0 ，那么 validate = false，即可以跳过表空间校验。实际测试的时候设置 innodb_force_recovery =1，也就是强制恢复跳过坏页，就可以跳过校验，然后重启就是正常启动了。通过这种临时方式可以避免崩溃恢复后非常耗时的表空间校验过程，快速启动 MySQL，个人目前暂时未发现有什么隐患。2 使用共享表空间替代独立表空间这样就不需要打开 N 个 ibd 文件了，只需要打开一个 ibdata 文件即可，大大节省了校验时间。自从听了姜老师讲过使用共享表空间替代独立表空间解决 drop 大表时性能抖动的原理后，感觉共享表空间在很多业务环境下，反而更有优势。

临时冒出另外一种解决想法，即用 GDB 调试崩溃恢复，通过临时修改 validate 变量值让 MySQL 跳过表空间验证过程，然后让 MySQL 正常关闭，重新启动就可以正常启动了。但是实际测试发现，如果以 debug 模式运行，确实可以临时修改 validate 变量，跳过表空间验证过程，但是 debug 模式下代码运行效率大打折扣，反而耗时更长。而以非 debug 模式运行，则无法修改 validate 变量，想法破灭。

限流算法目前程序开发过程常用的限流算法有两个：漏桶算法和令牌桶算法。

漏桶算法

漏桶算法的原理比较简单，请求进入到漏桶中，漏桶以一定的速率漏水。当请求过多时，水直接溢出。可以看出，漏桶算法可以强制限制数据的传输速度。如图所示，把请求比作是水滴，水先滴到桶里，通过漏洞并以限定的速度出水，当水来得过猛而出水不够快时就会导致水直接溢出，即拒绝服务。

来自网络

漏桶的出水速度是恒定的，那么意味着如果瞬时大流量的话，将有大部分请求被丢弃掉（也就是所谓的溢出）。

令牌桶算法

令牌桶算法的原理是系统以一定速率向桶中放入令牌，如果有请求时，请求会从桶中取出令牌，如果能取到令牌，则可以继续完成请求，否则等待或者拒绝服务。这种算法可以应对突发程度的请求，因此比漏桶算法好。

来自网络

漏桶算法和令牌桶算法的选择

两者的主要区别漏桶算法能够强行限制处理数据的速率，不论系统是否空闲。而令牌桶算法能够在限制数据的平均处理速率的同时还允许某种程度的突发流量。如何理解上面的含义呢？漏桶算法，比如系统吞吐量是 120/s，业务请求 130/s，使用漏斗限流 100/s，起到限流的作用，多余的请求将产生等待或者丢弃。对于令牌桶算法，每秒产生 100 个令牌，系统容量 200 个令牌。正常情况下，业务请求 100/s 时，请求能被正常被处理。当有突发流量过来比如 200 个请求时，因为系统容量有 200 个令牌可以同一时刻处理掉这 200 个请求。如果是漏桶算法，则只能处理 100 个请求，其他的请求等待或者被丢弃。

在老版本的MySQL 322中，MySQL的单表限大小为4GB，当时的MySQL的存储引擎还是ISAM存储引擎。但是，当出现MyISAM存储引擎之后，也就是从MySQL 323开始，MySQL单表最大限制就已经扩大到了64PB了（官方文档显示）。也就是说，从目前的技术环境来看，MySQL数据库的MyISAM存储 引擎单表大小限制已经不是有MySQL数据库本身来决定，而是由所在主机的OS上面的文件系统来决定了。

而MySQL另外一个最流行的存储引擎之一Innodb存储数据的策略是分为两种的，一种是共享表空间存储方式，还有一种是独享表空间存储方式。

当使用共享表空间存储方式的时候，Innodb的所有数据保存在一个单独的表空间里面，而这个表空间可以由很多个文件组成，一个表可以跨多个文件存在，所 以其大小限制不再是文件大小的限制，而是其自身的限制。从Innodb的官方文档中可以看到，其表空间的最大限制为64TB，也就是说，Innodb的单 表限制基本上也在64TB左右了，当然这个大小是包括这个表的所有索引等其他相关数据。

而当使用独享表空间来存放Innodb的表的时候，每个表的数据以一个单独的文件来存放，这个时候的单表限制，又变成文件系统的大小限制了。

与其他的大型数据库例如

Oracle、DB2、SQL

Server等相比，MySQL

自有它的不足之处，但是这丝毫也没有减少它受欢迎的程度。对于一般的个人使用者和中小型企业来说，MySQL提供的功能已经绰绰有余，而且由于

MySQL是开放源码软件，因此可以大大降低总体拥有成本。

企业生产MySQL是如何优化的呢？

参考答案:

a：硬件的优化：

1、

采用64位cpu，cpu至少4颗，L2缓存越大越好

2、

内存要大，32-64G运行1-2个实例，96-128G运行3-4个实例

3、

机械盘选用sas盘，转速15000以上，用可能的话使用ssd

4、

raid卡使用raid10

5、

网卡多块，千兆以上

6、

数据库不要使用虚拟化，slave硬件要好于master

b： *** 作系统优化

1、

*** 作系统选择x86_64位，尽量采用xfs文件系统

2、

优化磁盘存储参数

3、

优化内核参数

4、

优化网络等

c：mysql构架优化

1、根据内存大小，配置服务器跑多实例

2、主从复制采用mixed模式，尽量不要跨机房同步，若要跨机房，尽量采用远程写，本地读

3、定期检查、修复主从复制的数据差异

4、业务拆分，搜索功能不使用MySQL数据库执行；某些高并发，安全性一般的业务使用nosql，如：memcache、

redis等

5、数据库前端加cache，如memcache，用于用户登录，商品查询

6、动态数据静态化，整个文件静态化，页面片段静态化

7、数据库集群读写分离，一主多从，通过dbproxy进行集群读写分离

8、单表超过800万，拆库拆表，如人工将（登录、商品、订单）拆表拆库

9、选择从库备份，并且对数据库进行分表分库备份

d：MySQL数据库层面优化

1、

优化mycnf参数

2、

优化库表设计，包括字符集、字符串长度、创建短索引、多用复合索引；

3、

SQL语句优化，减少慢语句数量；

e：数据库管理流程、制度优化

1、

人的流程：开发—>核心运维/DBA

2、

测试流程：内网

IDC测试线上执行

3、

客户端管理，PHPMYADMIN

f：MySQL数据库安全优化

1、

数据库禁止设置外网

2、

数据库文件权限优化；

3、

授权用户权限限制，尽量专库专用户

4、

限制开发对生产库的 *** 作权限

5、

防止SQL语句注入

总结

本文关于企业生产MySQL优化介绍的先关内容就到这里，希望对大家有所帮助。感兴趣的朋友可以参阅：Oracle分页查询性能优化代码详解、ORACLE

SQL语句优化技术要点解析、C/C++

编译器优化介绍等内容，有什么问题可以随时留言，小编会及时回复大家的。

Mysql数据库只影响你论坛文本信息的多少。也就是你论坛的用户的用户信息和文章的内容都是从Mysql里面调也来给用户查看的。

用处是方便信息的调用和存贮。基本上要比ACCES要快。而且也要安全

以上就是关于如何使用PDO查询Mysql来避免SQL注入风险全部的内容，包括:如何使用PDO查询Mysql来避免SQL注入风险、频繁查询mysql数据库导致崩溃、关于MySQL高并发处理机制是如何实现等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！