无心云

具体的看了一下mysql的prepared_statement，发现它其实就是做了一个防止sql注入的工作，先解析一个statement，然后根据传上来的参数进行escape，然后重新组成一个sql，然后接下来的工作跟直接输入sql的区别不是很大了。具体哪个效率更高一些需要做些测试才能知道，但是首先从通用性上来说，这种方法已经不是很适合了，因为有时候prepared_state方式代码会很难写。

<br />mysql-proxy8.0里需要的模块如下：<br />lua >= 5.1<br />glib >= 2.16<br />gmodule >= 2.16<br />gthread >= 2.16<br />libevent >= 1.4<br /> <br />1、libevent<br />首先libevent可以直接用yum进行安装，yum search event，找到符合当前操作系统的版本，由于我的操作系统是64位，并且需要进行开发，因此选 libevent-devel.x8

看了点例子，根据mysql-proxy里的keepalive例子修改了一个支持主从分离，事务到主库，非事务查询到从库，以及连接断开时自动回滚的脚本，分享一下。--[[ $%BEGINLICENSE%$ Copyright (C) 2007-2008 MySQL AB, 2008 Sun Microsystems, Inc This program is free software; you can redistribute it and/or modify it under the terms

昨天晚上测试了一把mysql-proxy的性能，单纯的只是测试了一下select，发现差不多mysql-proxy可以1s处理2000多条请求，今天来部署了一下自己写的一个连接池，测试了一下，发现1s只能处理100多个，太受打击了。去研究一下linux下的profile工具，一定要看看这个差距是什么原因造成的，跟我想的也差太多了。

<br />今天掉到这个坑里了，mysql如果开了set autocommit=0，那么所有的语句一定是在一个事务里，在这种情况下，如果使用连接池，并且在查询之前没有rollback或者set autocommit=1，那么你就杯具了。因为根据mysql的默认事务级别，一致性读，你永远也取不到这个事务被开户前的数据。另外一点set autocommit= 0，会自动提交前一个事务，因此正确的作法是rollback, set autocommit =0，完成之后再set autocommit = 1;<br

 1.       背景为什么要使用MySQL-Proxy呢？MySQL-Proxy能带来什么样的好处？我们先来看一下正常的MySQL通信流程：很显然，我们可以在这些流程中间加入一个中间人，由它来将这些请求转发，接下来我们看一下如果加入一个中间人（MySQL-Proxy）的情况下，流程会变成什么样子，以及这种变化会带给我们什么样的好处。上图中红线部分都表示MySQL-Proxy可能篡改的地方。而proxy_xxx方法表示MySQL-Proxy可以拦截并提供给使用者进行篡改的途径。事实上MySQL-Proxy

今天在测试自己写的异步mysql库时发现mysql 居然不认schema.table这种格式的sql，折腾了好久才发现原来是client_flag导致的，因此将所有的client_flag参数列出来如下#define CLIENT_LONG_PASSWORD    1   /* new more secure passwords */#define CLIENT_FOUND_ROWS