数据库SQL语句的安全方案
1.必须禁用字符串操作的方式来组合执行SQL语句。而使用预编译语句 Prepared statements 来生成 并执行SQL 的请求。
2.服务端代码中使用字符串拼接的方式来生成SQL语句进行UPDATE，INSERT是很常见的。
我们通常会用 escape_string 的方式来进行转义来防止SQL注入。
这种操作方式进行操作数据库存在的风险非常高。除了SQL注入漏洞的风险之外。在实际项目中它还会出现一些更难以预防的风险，内存错误等问题。
根据谷歌官方曾经披露的数据，繁忙的业务集群中，每8GB内存每小时的错误率高达5个bit。当然服务器必须使用ECC内存。但虽然ECC内存中每 64bit 的 word 中发生1 bit 错误时可以被控制器修正。
但如果发生2个bit的错误时，就无法被修正了。那么计算一下，ECC内存发生无法修复的内存错误的概率是：每8GB每小时 1/2.2737368e-11。看上去好像很低。但是如果是一组200台x每台512G内存的服务器集群，一年内发生无法修正的内存错误的概率可以高达达到千分之2.5。
比如一段SQL代码本来是 UPDATE data=‘xxxx’, b=10003 WHERE n=8888 。因为错了一个bit, 3变成#。语句变成 UPDATE data=‘xxxx’, b=1000# WHERE n=8888 。我们知道 # 是 mysql 行内注释，所以这个语句还能正常执行，只是没有了 WHERE 条件，并把整个库的所有用户数据都 update 了……
比较好的解决方案是：使用 MySQL 的预编译语句 Prepared statements 来生成 SQL 请求。这样做的好处，不仅是防止 SQL 语句出错甚至被注入。而且还能获得更高性能。
更多安全技术文章，请关注 “游戏安全攻防” 公众号，一起学习，一起进步。