产品中心
MySQL在服务器端提供只读的、单向的游标，而且只能在存储过程或者更底层的客户端API中使用。
因为MySQL游标中指向的对象都是存储在临时表中而不是实际查询到的数据，所以MySQL游标总是只读的。它可以逐行指向查询结果，然后让程序做进一步的处理。在一个存储过程中，可以有多个游标，也可以在循环中“嵌套”地使用游标。
MySQL的游标设计也为粗心的人“准备”了陷阱。因为是使用临时表实现的，所以它在效率上给开发人员一个错觉。需要记住的最重要的一点是：当你打开一个游标的时候需要执行整个查询。
考虑下面的存储过程：
当服务器收到这些SQL语句后，先会像一般客户端的链接库一样将其翻译成对应的操作。
这意味着你无须使用二进制协议也可以使用绑定变量。
正如你看到的，比起直接编写的SQL语句，这里的语法看起来有一些怪怪的。
那么，这种写法实现的绑定变量到底有什么优势呢？
最主要的用途就是在存储过程中使用。在MySQL 5.0版本中，就可以在存储过程中使用绑定变量，其语法和前面介绍的SQL接口的绑定变量类似。这意味，可以在存储过程中构建并执行“动态”的SQL语句，这里的
“动态”是指可以通过灵活地拼接字符串等参数构建SQL语句。例如，下面的示例存储过程中可以针对某个数据库执行OPTIMIZE TABLE的操作：
可以这样调用这个存储过程：
另一种实现存储过程中循环的办法是：
这两种循环结构最重要的区别在于：REPEAT会为每个循环检查两次循环条件。在这个例子中，因为循环条件检查的是一个整数判断，并不会有什么性能问题，如果循环的判断条件非常复杂的话，则需要注意这两者的区别。
像这样使用SQL接口的绑定变量拼接表名和库名是很常见的，这样的好处是无须使用任何参数就能完成SQL语句。而库名和表名都是关键字，在二进制协议的绑定变量中是不能将这两部分参数化的。另一个经常需要动态设置的就是LIMIT子句，因为二进制协议中也无法将这个值参数化。
另外，编写存储过程时，SQL接口的绑定变量通常可以很大程度地帮助我们调试绑定变量，如果不是在存储过程中，SQL接口的绑定变量就不是那么有用了。因为SQL接口的绑定变量，它既没有使用二进制传输协议，也没有能够节省带宽，相反还总是需要增加至少一次额外网络传输才能完成一次查询。所有只有在某些特殊的场景下SQL接口的绑定变量才有用，比如当SQL语句非常非常长，并且需要多次执行的时候。
关于绑定变量的一些限制和注意事项如下：
1.绑定变量是会话级别的，所以连接之间不能共用绑定变量句柄。同样地，一旦连接断开，则原来的句柄也不能再使用了。（连接池和持久化连接可以在一定程度上缓解这个问题。）
2.在MySQL 5.1版本之前，绑定变量的SQL是不能使用查询缓存的。
3.并不是所有的时候使用绑定变量都能获得更好的性能。如果只是执行一次SQL，那么使用绑定变量方式无疑比直接执行多了一次额外的准备阶段消耗，而且还需要一次额外的网络开销。（要正确地使用绑定变量，还需要在使用完成后，释放相关的资源。）
4.当前版本下，还不能在存储函数中使用绑定变量（但是存储过程中可以使用）。
5.如果总是忘记释放绑定变量资源，则在服务器端很容易发生资源“泄漏”。绑定变量 SQL总数的限制是一个全局限制，所以某一个地方的错误可能会对所有其他的线程都产生影响。
6.有些操作，如BEGIN，无法在绑定变量中完成。
不过使用绑定变量最大的障碍可能是：
它是如何实现以及原理是怎样的，这两点很容易让人困惑。有时，很难解释如下三种绑定变量类型之间的区别是什么：
1.客户端模拟的绑定变量
2.服务器端的绑定变量
3.SQL接口的绑定变量
参考:《高性能MySQL》
以上为个人经验，希望能给大家一个参考，也希望大家多多支持。
