Nov29

MySQL除法精度问题

Author: leeon  Click: 978   Comments: 0 Category: 数据库  Tag: mysql

最近在写一个SQL中遇到除法精度问题,比如:

[code="sql"]
SELECT 7185521/7185522
[/code]

得出的结果是1,那么如何让他得到0.999这样的结果呢,后来查google得知可以利用TRUNCATE()函数来解决这样类似大数据除法的精度问题。

  • TRUNCATE(X,D)

返回被舍去至小数点后D位的数字X。若D 的值为 0, 则结果不带有小数点或不带有小数部分。可以将D设为负数,若要截去(归零) X小数点左起第D位开始后面所有低位的值.

[code="sql"]
SELECT TRUNCATE(7185521/7185522,4)
[/code]

例如这样就会得出“0.9999”这样的结果

Nov15

MySQL中删除用户授权的方法

Author: leeon  Click: 868   Comments: 0 Category: 数据库  Tag: mysql,grant,revke
撤权并删除用户
  要取消一个用户的权限,使用REVOKE语句。REVOKE的语法非常类似于GRANT语句,除了TO用FROM取代并且没有INDETIFED BY和WITH GRANT OPTION子句:

  REVOKE privileges (columns) ON what FROM user

  user部分必须匹配原来 GRANT语句的你想撤权的用户的user部分。privileges部分不需匹配,你可以用GRANT语句授权,然后用REVOKE语句只撤销部分权限。
  REVOKE语句只删除权限,而不删除用户。即使你撤销了所有权限,在user表中的用户记录依然保留,这意味着用户仍然可以连接服务器。要完全删除一个用户,你必须用一条Delete语句明确从user表中删除用户记录:
%mysql -u root mysqlmysql>Delete FROM user ->Where User="user_name" and Host="host_name";mysql>FLUSH PRIVILEGES;

  Delete语句删除用户记录,而FLUSH语句告诉服务器重载授权表。(当你使用GRANT和REVOKE语句时,表自动重载,而你直接修改授权表时不是。)
Oct31

MySQL锁机制/管理(并发锁,行锁,表锁,预加锁,全局锁等等)

Author: mysqlab.net  Click: 587   Comments: 0 Category: 数据库  Tag: mysql

1. MySQL中并发和隔离控制机制

  • Meta-data元数据锁:在table cache缓存里实现的,为DDL(Data Definition Language)提供隔离操作。一种特别的meta-data元数据类型,叫Name Lock。(SQL层)
  • 表级table-level数据锁(SQL层)
  • 存储引擎特有机制 — row locks行锁,page locks页锁,table locks表级,版本控制(在引擎中实现)
  • 全局读锁 — FLUSH TABLES WITH READ LOCK(SQL层)

2.在语句执行中表的生命周期

DML(Data Manipulation Language):

  • 计算语句使用到的所有表
  • 在每个表:打开open表 — 从table cache缓存里得到TABLE对象,并在此表加上meta-data元数据锁
  • 等待全局读锁后改变数据
  • 在每个表:锁lock表 — 在表加上table-level数据锁
  • 执行语句:调用:handler::write_row()/read_rnd()/read_index(),等;隐式地调用引擎级engine-level锁机制
  • 在每个表:释放表的数据锁
  • 在每个表:释放表的DDL锁并把表放回table cache缓存里
  • DDL语句也是一样,没有典型的执行计划。

3.获取meta-data元数据锁

  • meta-data元数据锁的实现作为TABLE对象的一个属性,TABLE对象代表了table cache缓存。
  • meta-data元数据锁为如下任何一种:
    • shared共享锁 — 隐式地加锁,只通过标记TABLE对象“被使用”;
    • semi-exclusive半独享锁,也叫Name Lock,RENAME操作会在源表和目标加上此锁;
    • exclusive独享,也叫exclusive name lock,CREATE TABLE … SELECT操作会在目标表上加上此锁,如果没有的话。

4.表缓存(table cache)

  • 是一个HASH变量,叫open_cache
  • TABLE对象是HASH元素
  • 以HASH的操作被LOCK_open mutex互斥量保护

4.1内部结构(The table cache: internal structure)

  • 在缓存里,每个物理表可能被多个TABLE实例表示
  • 相同表的所有TABLE实例,通过相连的列(a linked list)连接着
  • 每个TABLE实例有一个table cache缓存版本的复制 — TABLE实例保存的版本不会和当前table cache缓存版本一致,而是保存旧的和从缓存删除的
  • 被某些语句使用的TABLE实例被会标记为对其它的语句来说是无效的 — 这就是meta-data元数据锁的本质
  • 在缓存中的TABLE实例通常地有一个有效的句柄实例连接着它

4.2内部运算(The table cache: operations)

  • 主要的代码在:sql/sql_base.cc,sql/lock.cc,sql/table.h,sql/sql_table.cc
  • 主要的方法:open_table(),close_thread_tables(),close_cached_table(),lock_table_names()
  • 事实上,一个概念/对象组合不仅用于缓存或锁定:LOCK_open mutex互斥量也用到其它的操作,如:使磁盘上和处理中的表创建的原子性
  • 典型的操作,来自隔离等级Pov的重要(注:isolation PoV没研究出是什么意思):语句查询时,打开和关闭表 — shared共享锁;强制和等待直到表的所有实例被关闭 —  exclusive独享(但不完全);Name Lock — 特殊地情况,当手上没有TABLE实例,只能使用一个特殊的占位符(甚至表可能不存在)。

4.4锁多表(The table cache: locking multiple tables)

  • 使用一种尝试和回退(try and back-off)的技术来避免死锁(乐观锁)
  • 为了DDL操作的一套诀窍,如使锁升级或者防止DDL失效
  • LOCK_open问题
  • Lock_open互斥量:
  • 保护table cache缓存内的结构
  • 分组存储引擎内的表和对象的.frm文件的创建,也为RENAME操作提供原子性操作
  • 在每个语句访问表时会使用它两次:在open_tables()和close_thread_tables()
  • 在使用DDL操作时,磁盘读写和甚至同步(sync)都会使用它

5.ALTER TABLE例子

ALTER TABLE执行的简化计划:

  • 以TL_WRITE_ALLOW_READ的打开和加锁表(新版 InnoDB Plugin已改为:TL-READ-NO-INSERT)
  • 创建一个以临时名字的被ALTER的复制表
  • 强制并等待直到表的所有实例都关闭(锁升级)
  • 交换新和旧的版本
  • 删除旧的版本

这是一般情况,当然还有优化的情况。

A debug trace for ALTER TABLE

  1. T@8: | query: alter table t1 add column k int
  2. T@8: | >mysql_parse
  3. T@8: | | >mysql_execute_command
  4. T@8: | | | >mysql_alter_table
  5. T@8: | | | | >open_ltable
  6. T@8: | | | | | >open_table
  7. T@8: | | | | | <open_table
  8. T@8: | | | | | >mysql_lock_tables
  9. T@8: | | | | | | >get_lock_data
  10. T@8: | | | | | | | >ha_innobase::store_lock
  11. T@8: | | | | | | | <ha_innobase::store_lock
  12. T@8: | | | | | | <get_lock_data
  13. T@8: | | | | | | >lock_external
  14. T@8: | | | | | | | >ha_innobase::external_lock
  15. T@8: | | | | | | | | enter: lock_type: 1
  16. T@8: | | | | | | | | >trans_register_ha
  17. T@8: | | | | | | | | | enter: stmt
  18. T@8: | | | | | | | | <trans_register_ha
  19. T@8: | | | | | | | <ha_innobase::external_lock
  20. T@8: | | | | | | <lock_external
  21. T@8: | | | | | | >thr_multi_lock
  22. T@8: | | | | | | | >thr_lock
  23. T@8: | | | | | | | <thr_lock
  24. T@8: | | | | | | <thr_multi_lock
  25. T@8: | | | | | <mysql_lock_tables
  26. T@8: | | | | <open_ltable
  27. T@8: | | | | >mysql_create_table
  28. T@8: | | | | <mysql_create_table
  29. T@8: | | | | >open_temporary_table
  30. T@8: | | | | | >openfrm
  31. T@8: | | | | | | >handler::ha_open
  32. T@8: | | | | | | | enter: name: ./test/#sql-3081_1 db_type: 12 db_stat: 7 mode: 2 lock_test: 2
  33. T@8: | | | | | | | >ha_innobase::open
  34. T@8: | | | | | | | <ha_innobase::open
  35. T@8: | | | | | | <handler::ha_open
  36. T@8: | | | | | <openfrm
  37. T@8: | | | | <open_temporary_table
  38. T@8: | | | | >copy_data_between_tables
  39. T@8: | | | | <copy_data_between_tables
  40. T@8: | | | | >closefrm
  41. T@8: | | | | <closefrm
  42. T@8: | | | | >close_cached_table
  43. T@8: | | | | | enter: table: t1
  44. T@8: | | | | | >wait_while_table_is_used
  45. T@8: | | | | | | >get_lock_data
  46. T@8: | | | | | | <get_lock_data
  47. T@8: | | | | | | >thr_abort_locks
  48. T@8: | | | | | | <thr_abort_locks
  49. T@8: | | | | | | >remove_table_from_cache
  50. T@8: | | | | | | | enter: Table: ‘test.t1′ flags: 2
  51. T@8: | | | | | | <remove_table_from_cache
  52. T@8: | | | | | <wait_while_table_is_used
  53. T@8: | | | | | >mysql_unlock_tables
  54. T@8: | | | | | | >thr_multi_unlock
  55. T@8: | | | | | | | lock: data: 0x8b7f9b0 count: 1
  56. T@8: | | | | | | | >thr_unlock
  57. T@8: | | | | | | | <thr_unlock
  58. T@8: | | | | | | <thr_multi_unlock
  59. T@8: | | | | | | >unlock_external
  60. T@8: | | | | | | | >ha_innobase::external_lock
  61. T@8: | | | | | | | <ha_innobase::external_lock
  62. T@8: | | | | | | <unlock_external
  63. T@8: | | | | | <mysql_unlock_tables
  64. T@8: | | | | | >unlink_open_table
  65. T@8: | | | | | | >hash_delete
  66. T@8: | | | | | | | >free_cache_entry
  67. T@8: | | | | | | | | >closefrm
  68. T@8: | | | | | | | | | >ha_innobase::close
  69. T@8: | | | | | | | | | <ha_innobase::close
  70. T@8: | | | | | | | | <closefrm
  71. T@8: | | | | | | | <free_cache_entry
  72. T@8: | | | | | | <hash_delete
  73. T@8: | | | | | <unlink_open_table
  74. T@8: | | | | <close_cached_table
  75. T@8: | | | | >mysql_rename_table
  76. T@8: | | | | | >ha_innobase::rename_table
  77. T@8: | | | | | <ha_innobase::rename_table
  78. T@8: | | | | <mysql_rename_table
  79. T@8: | | | | >mysql_rename_table
  80. T@8: | | | | | >ha_innobase::rename_table
  81. T@8: | | | | | <ha_innobase::rename_table
  82. T@8: | | | | <mysql_rename_table
  83. T@8: | | | | >my_delete
  84. T@8: | | | | | my: name ./test/#sql2-3081-1.frm MyFlags 0
  85. T@8: | | | | <my_delete
  86. T@8: | | | | >ha_delete_table
  87. T@8: | | | | | >ha_innobase::delete_table
  88. T@8: | | | | | <ha_innobase::delete_table
  89. T@8: | | | | <ha_delete_table
  90. T@8: | | | | >ha_commit_trans T@8: | | | | <ha_commit_trans T@8: | | | | >ha_commit_trans T@8: | | | | <ha_commit_trans T@8: | | | <mysql_alter_table
  91. T@8: | | <mysql_execute_command
  92. T@8: | <mysql_parse
  93. T@8: <dispatch_command

6.RENAME TABLE例子

  • 得到源表和目的表的name-lock锁:在table cache缓存内插入特殊的TABLE实例的占位符并等待直到这些表的所有实例都关闭
  • 重命名这些表的.frm文件和调用handler::rename_table()方法
  • 删除name-lock锁

在整个解析过程中,都使用LOCK_open

Simplified debug trace for RENAME TABLE

  1. T@10: | query: rename table t1 to t2
  2. T@10: | >mysql_parse
  3. T@10: | | >mysql_execute_command
  4. T@10: | | | >mysql_rename_tables
  5. T@10: | | | | >lock_table_names
  6. T@10: | | | | | >lock_table_name
  7. T@10: | | | | | | enter: db: test name: t1
  8. T@10: | | | | | <lock_table_name
  9. T@10: | | | | | >remove_table_from_cache
  10. T@10: | | | | | | enter: Table: ‘test.t1′ flags: 0
  11. T@10: | | | | | | >hash_delete
  12. T@10: | | | | | | | >free_cache_entry
  13. T@10: | | | | | | | | >closefrm
  14. T@10: | | | | | | | | | >ha_innobase::close
  15. T@10: | | | | | | | | | <ha_innobase::close
  16. T@10: | | | | | | | | <closefrm
  17. T@10: | | | | | | | <free_cache_entry
  18. T@10: | | | | | | <hash_delete
  19. T@10: | | | | | <remove_table_from_cache
  20. T@10: | | | | | >lock_table_name
  21. T@10: | | | | | | enter: db: test name: t2
  22. T@10: | | | | | <lock_table_name
  23. T@10: | | | | | >remove_table_from_cache
  24. T@10: | | | | | | enter: Table: ‘test.t2′ flags: 0
  25. T@10: | | | | | <remove_table_from_cache
  26. T@10: | | | | <lock_table_names
  27. T@10: | | | | >rename_tables
  28. T@10: | | | | | >do_rename
  29. T@10: | | | | | | >mysql_rename_table
  30. T@10: | | | | | | | >ha_innobase::rename_table
  31. T@10: | | | | | | | <ha_innobase::rename_table
  32. T@10: | | | | | | | >my_rename
  33. T@10: | | | | | | | | my: from ./test/t1.frm to ./test/t2.frm MyFlags 16
  34. T@10: | | | | | | | <my_rename
  35. T@10: | | | | | | <mysql_rename_table
  36. T@10: | | | | | <do_rename
  37. T@10: | | | | <rename_tables
  38. T@10: | | | | >unlock_table_names
  39. T@10: | | | | | >unlock_table_name
  40. T@10: | | | | | | >hash_delete
  41. T@10: | | | | | | | >free_cache_entry
  42. T@10: | | | | | | | <free_cache_entry
  43. T@10: | | | | | | <hash_delete
  44. T@10: | | | | | <unlock_table_name
  45. T@10: | | | | | >unlock_table_name
  46. T@10: | | | | | | >hash_delete
  47. T@10: | | | | | | | >free_cache_entry
  48. T@10: | | | | | | | <free_cache_entry
  49. T@10: | | | | | | <hash_delete
  50. T@10: | | | | | <unlock_table_name
  51. T@10: | | | | <unlock_table_names
  52. T@10: | | | <mysql_rename_tables
  53. T@10: | | <mysql_execute_command
  54. T@10: | <mysql_parse

7.表级table-level锁

  • 主要源代码见:sql/lock.cc,mysys/thr_lock.cc。mysql_lock/unlock_tables()(SQL层操作)和thr_multi_lock()/thr_lock()(锁兼容逻辑lock-compatibility logic)
  • 表是以打开着被加锁的。被加锁的对象被句柄关联着;存储引擎会调整锁的类型。如innodb/bdb,事实上大量的对象被加锁的,如merge/partition,见handler::store_lock()方法。
  • 使用锁等级避免死锁。所有表一次性加锁;如果存储引擎调整锁造成死锁,由存储引擎负责
  • 在一些情况下,表会更早地被解锁

8 .预加锁(pre-locking)

  • 历史上避免死锁方案用于表级table-level数据锁,是要求一次性加锁一个语句内的所有表
  • 因此,对语句使用的函数/触发,我们不得不打开所有直接地或间接地用到的表,且对它们加锁。为这个,我们建立一个被使用表的可传送闭包
  • 为了有效实现,我们混合层次和访问(layers and access)成某些解析/语句上下文(parser/statement context),这些上下文来自主要处理表的模板

9.全局读锁(global read lock)

  • 实现为FLUSH TABLES WITH READ LOCK,用来备份
  • 从执行上防止DDL和DML
  • 建议:每个DDL/DML语句检查是否有一个正挂着的全局读锁和停止是否有任何一个。
    • 通过直接调用wait_if_global_read_lock()(在这个情况我们会设置来自全局读锁的保护,且只有调用start_waiting_global_read_lock()来消除这个保护,通常在这情况下没有打开的表);
    • 或者通过mysql_lock_tables()(在后一种情况下,我们还重新打开表)
  • 线程操作FLUSH TABLES WITH READ LOCK来设置一个全局读锁的标识,初始一个FLUSH TABLES语句,然后等待直到所有的表缓存都清空
Oct29

MySQL锁表机制

Author: leeon  Click: 951   Comments: 0 Category: 数据库  Tag: 数据库,锁表,mysql
1、 锁机制
当前MySQL已经支持 ISAM, MyISAM, MEMORY (HEAP) 类型表的表级锁了,BDB 表支持页级锁,InnoDB 表支持行级锁。
很多时候,可以通过经验来猜测什么样的锁对应用程序更合适,不过通常很难说一个锁比别的更好,这全都要依据应用程序来决定,不同的地方可能需要不同的锁。
想要决定是否需要采用一个支持行级锁的存储引擎,就要看看应用程序都要做什么,其中的查询、更新语句是怎么用的。例如,很多的web应用程序大量的做查询,很少删除,主要是基于索引的更新,只往特定的表中插入记录。采用基本的MySQL MyISAM 表就很合适了。
MySQL中对表级锁的存储引擎来说是释放死锁的。避免死锁可以这样做到:在任何查询之前先请求锁,并且按照请求的顺序锁表。
MySQL中用于 WRITE(写) 的表锁的实现机制如下:
如果表没有加锁,那么就加一个写锁。
否则的话,将请求放到写锁队列中。
MySQL中用于 READ(读) 的表锁的实现机制如下:
如果表没有加写锁,那么就加一个读锁。
否则的话,将请求放到读锁队列中。
当锁释放后,写锁队列中的线程可以用这个锁资源,然后才轮到读锁队列中的线程。
这就是说,如果表里有很多更新操作的话,那么 Select 必须等到所有的更新都完成了之后才能开始。
从 MySQL 3.23.33 开始,可以通过状态变量 Table_locks_waited 和 Table_locks_immediate 来分析系统中的锁表争夺情况:
[code="sql"]
mysql> SHOW STATUS LIKE 'Table%';
+-----------------------+---------+
| Variable_name | Value |
+-----------------------+---------+
|Table_locks_immediate | 1151552 |
| Table_locks_waited | 15324 |
+-----------------------+---------+
[/code]
在 MySQL 3.23.7(在Windows上是3.23.25)以后,在 MyISAM 表中只要没有冲突的 Insert 操作,就可以无需使用锁表自由地并行执行 Insert 和 Select 语句。也就是说,可以在其它客户端正在读取 MyISAM 表记录的同时时插入新记录。如果数据文件的中间没有空余的磁盘块的话,就不会发生冲突了,因为这种情况下所有的新记录都会写在数据文件的末尾(当在表的中间做删除或者更新操作时,就可能导致空洞)。当空洞被新数据填充后,并行插入特性就会自动重新被启用了。
如果想要在一个表上做大量的 Insert 和 Select 操作,但是并行的插入却不可能时,可以将记录插入到临时表中,然后定期将临时表中的数据更新到实际的表里。可以用以下命令实现:
[code="sql"]
mysql> LOCK TABLES real_table WRITE, insert_table WRITE;
mysql> Insert INTO real_table Select * FROM insert_table;
mysql> TRUNCATE TABLE insert_table;
mysql> UNLOCK TABLES;
[/code]InnoDB 使用行级锁,BDB 使用页级锁。对于 InnoDB 和 BDB 存储引擎来说,是可能产生死锁的。这是因为 InnoDB 会自动捕获行锁,BDB 会在执行 SQL 语句时捕获页锁的,而不是在事务的开始就这么做。
行级锁的优点有:
在很多线程请求不同记录时减少冲突锁。
事务回滚时减少改变数据。
使长时间对单独的一行记录加锁成为可能。
行级锁的缺点有:
比页级锁和表级锁消耗更多的内存。
当在大量表中使用时,比页级锁和表级锁更慢,因为他需要请求更多的锁资源。
当需要频繁对大部分数据做 GROUP BY 操作或者需要频繁扫描整个表时,就明显的比其它锁更糟糕。
使用更高层的锁的话,就能更方便的支持各种不同的类型应用程序,因为这种锁的开销比行级锁小多了。
表级锁在下列几种情况下比页级锁和行级锁更优越:
很多操作都是读表。
在严格条件的索引上读取和更新,当更新或者删除可以用单独的索引来读取得到时:
[code="sql"]
Update tbl_name SET column=value Where unique_key_col=key_value;
Delete FROM tbl_name Where unique_key_col=key_value;
[/code]Select 和 Insert 语句并发的执行,但是只有很少的 Update 和 Delete 语句。
很多的扫描表和对全表的 GROUP BY 操作,但是没有任何写表。
表级锁和行级锁或页级锁之间的不同之处还在于:
将同时有一个写和多个读的地方做版本(例如在MySQL中的并发插入)。也就是说,数据库/表支持根据开始访问数据时间点的不同支持各种不同的试图。其它名有:时间行程,写复制,或者是按需复制。
原文: Versioning (such as we use in MySQL for concurrent inserts) where you can have one writer at the same time as many readers. This means that the database/table supports different views for the data depending on when you started to access it. Other names for this are time travel, copy on write, or copy on demand.
按需复制在很多情况下比页级锁或行级锁好多了。尽管如此,最坏情况时还是比其它正常锁使用了更多的内存。
可以用应用程序级锁来代替行级锁,例如MySQL中的 GET_LOCK() 和 RELEASE_LOCK()。但它们是劝告锁(原文:These are advisory locks),因此只能用于安全可信的应用程序中。
2、 锁表
为了能有快速的锁,MySQL除了 InnoDB 和 BDB 这两种存储引擎外,所有的都是用表级锁(而非页、行、列级锁)。
对于 InnoDB 和 BDB 表,MySQL只有在指定用 LOCK TABLES 锁表时才使用表级锁。在这两种表中,建议最好不要使用 LOCK TABLES,因为 InnoDB 自动采用行级锁,BDB 用页级锁来保证事务的隔离。
如果数据表很大,那么在大多数应用中表级锁会比行级锁好多了,不过这有一些陷阱。
表级锁让很多线程可以同时从数据表中读取数据,但是如果另一个线程想要写数据的话,就必须要先取得排他访问。正在更新数据时,必须要等到更新完成了,其他线程才能访问这个表。
更新操作通常认为比读取更重要,因此它的优先级更高。不过最好要先确认,数据表是否有很高的 Select 操作,而更新操作并非很‘急需’。
表锁在一个线程在等待,因为磁盘空间满了,但是却需要有空余的磁盘空间,这个线程才能继续处理时就有问题了。这种情况下,所有要访问这个出问题的表的线程都会被置为等待状态,直到有剩余磁盘空间了。

表锁在以下设想情况中就不利了:
一个客户端提交了一个需要长时间运行的 Select 操作。
其他客户端对同一个表提交了 Update 操作,这个客户端就要等到 Select 完成了才能开始执行。
其他客户端也对同一个表提交了 Select 请求。由于 Update 的优先级高于 Select,所以 Select 就会先等到 Update 完成了之后才开始执行,它也在等待第一个 Select 操作。

下列所述可以减少表锁带来的资源争夺:
让 Select 速度尽量快,这可能需要创建一些摘要表。
启动 mysqld 时使用参数 --low-priority-updates。这就会让更新操作的优先级低于 Select。这种情况下,在上面的假设中,第二个 Select 就会在 Insert 之前执行了,而且也无需等待第一个Select 了。
可以执行 SET LOW_PRIORITY_UpdateS=1 命令,指定所有的更新操作都放到一个指定的链接中去完成。详情请看“14.5.3.1 SET Syntax”。
用 LOW_PRIORITY 属性来降低 Insert,Update,Delete 的优先级。
用 HIGH_PRIORITY 来提高 Select 语句的优先级。详情请看“14.1.7 Select Syntax”。
从MySQL 3.23.7 开始,可以在启动 mysqld 时指定系统变量 max_write_lock_count 为一个比较低的值,它能强制临时地提高表的插入数达到一个特定值后的所有 Select 操作的优先级。它允许在 WRITE 锁达到一定数量后有 READ 锁。
当 Insert 和 Select 一起使用出现问题时,可以转而采用 MyISAM 表,它支持并发的Select 和 Insert 操作。
当在同一个表上同时有插入和删除操作时,Insert DELAYED 可能会很有用。详情请看“14.1.4.2 Insert DELAYED Syntax”。
当 Select 和 Delete 一起使用出现问题时,Delete 的 LIMIT 参数可能会很有用。详情请看“14.1.1 Delete Syntax”
执行 Select 时使用 SQL_BUFFER_RESULT 有助于减短锁表的持续时间.详情请看“14.1.7 Select Syntax”。
可以修改源代码 `mysys/thr_lock.c',只用一个所队列。这种情况下,写锁和读锁的优先级就一样了,这对一些应用可能有帮助。
以下是MySQL锁的一些建议:
只要对同一个表没有大量的更新和查询操作混在一起,目前的用户并不是问题。
执行 LOCK TABLES 来提高速度(很多更新操作放在一个锁之中比没有锁的很多更新快多了)。将数据拆分开到多个表中可能也有帮助。
当MySQL碰到由于锁表引起的速度问题时,将表类型转换成 InnoDB 或 BDB 可能有助于提高性能。详情请看“16 The InnoDB Storage Engine”和“15.4 The BDB (BerkeleyDB) Storage Engine”。

分类

标签

归档

最新评论

王爷在21:32:04评论了
【原创】获取jQuery中Ajax函数的返回值的方法
Funny在10:22:51评论了
shell数组使用方法小记
kevinems在11:30:08评论了
【原创】使用gitosis和tortoisegit打造自己的git服务
candy在13:11:40评论了
【原创】beautifulsoup解析中文网页乱码解决
thenbsp.com在16:17:48评论了
中国邮政EMS就是一坨屎

我看过的书

链接

其他

访问本站种子 本站平均热度:1218 c° 本站链接数:55 个 本站标签数:250 个 本站被评论次数:33 次