Monthly Archives: January 2009

MySQL当前提供只读，前向服务器端游标。这使得你在查询结果上逐行迭代取出每行到变量便于进一步处理。一个存储过程能有多个游标同时打开，并且可以在循环中嵌套游标。 MySQL也许将来会提供可更新的游标。游标是只读的因为它们在临时表上迭代而不是产生数据的原始的那个表。 MySQL的游标设计使得开发者会产生错觉，重要的是要记住当你打开游标的时候游标执行了整个查询。考虑下面的过程： create procedure bad_cursor() begin declare film_id int; declare f cursor for select film_id from sakila.film; open f; fetch f into film_id; close f; end 在Oracle或者SQL Server中也许没什么问题，但是在MySQL中引起了很多不必要的工作，包括1000次索引读取和1000此插入。因为在sakila.film表中有1000行。所有的1000次读和写发生在第5行，在第6行执行之前。 本意是说从大的数据集中尽早关闭游标，如果只需要较少的行，使用limit。 游标也能引起MySQL做很多额外的IO操作，可能导致很慢的结果。因为内存中的临时表不支持BLOB和TEXT字段，MySQL不得不创建磁盘临时表，即使这并不是问题，但是在临时表大小超过tmp_table_size时，MySQL将在磁盘上创建。

MySQL的查询优化器在存储过程和函数上有一些限制： 1、优化器没有在存储函数中使用 DETERMINISTIC 修饰符来优化单个查询中的多次调用。 2、优化器当前也不能估计执行一个存储函数的代价。 3、每个连接有自己的存储过程执行计划的cache。如果很多连接调用同样的过程，则会对同样的执行计划cache很多遍。如果使用连接池或者持久连接，则执行计划的cache会有比较长的使用寿命。 4、当和复制结合时很有意思。因为你可能并不要复制对它们的调用，你只想复制对受影响数据集确切的改变，在5.1中引入的行级复制有助减轻这个问题。如果在5.0中启用二进制日志，服务器将认为你将所有存储过程定义为DETERMINISTIC或者启用了 log_bin_trust_function_creators 选项。

InnoDB和查询Cache InnoDB以一种更加复杂的方式来和查询cache交互，因为MVCC的存在。在MySQL 4.0中，使用事务时完全不启用查询cache，但是在MySQL 4.1和更新的版本中，InnoDB可以在表一级的基础上，使用事务时可以访问查询cache。它控制着对查询cache的读和写。

下面有一些参数需要关注： query_cache_type query_cache_size query_cache_min_res_unit query_cache_limit query_cache_wlock_invalidate

MySQL查询缓存(query cache)保存一个完整查询返回给客户端的精确字节。当一个查询缓存命中发生时，服务器端能简单返回存储的结果，跳过解析、优化和执行的步骤。 查询缓存跟踪每个查询使用过的表，如果其中任何表改变，它将使得跟此表相关的缓存的条目失效。这么粗粒度的失效策略似乎不好——因为对表的改变可能没有影响到存储在cache中的结果——但是这是一个相对简单的方法，具有相对较低的处理代价。 查询缓存被设计为对应用完全透明。应用不需要知道MySQL是从cache还是实际执行了查询。

MySQL Stored Procedure Programming 1、The use of stored programs can lead to a more secure database.某些时候你看不到数据库结构。 2、Stored programs offer a mechanism to abstract data access routines, which can improve the maintainability of your code as underlying data structures evolve. 3、Stored … Continue reading →