- 浏览: 610433 次
- 性别:
- 来自: 北京
文章分类
最新评论
-
kangh:
转载的也拿出来 都不试一下 完全错误
Nginx+ffmpeg的HLS开源服务器搭建配置及开发详解 -
wangtxlz:
#cd builders/cmake#cmake .系统提示命 ...
crtmpserver流媒体服务器的介绍与搭建 -
hnraysir:
支持支持支持
手机Android音视频采集与直播推送,实现单兵、移动监控类应用 -
wuent:
把web服务器和php框架绑定到一起?真不建议这样。。。
Swoole(PHP高级Web开发框架) -
wuent:
有更详细的性能比较吗?php,python,java
PHP中的(伪)多线程与多进程
MySQL存储过程之事务管理
ACID:Atomic、Consistent、Isolated、Durable
存储程序提供了一个绝佳的机制来定义、封装和管理事务。
1,MySQL的事务支持
MySQL的事务支持不是绑定在MySQL服务器本身,而是与存储引擎相关:
隔离级别:
隔离级别决定了一个session中的事务可能对另一个session的影响、并发session对数据库的操作、一个session中所见数据的一致性
ANSI标准定义了4个隔离级别,MySQL的InnoDB都支持:
可以使用如下语句设置MySQL的session隔离级别:
MySQL默认的隔离级别是REPEATABLE READ,在设置隔离级别为READ UNCOMMITTED或SERIALIZABLE时要小心,READ UNCOMMITTED会导致数据完整性的严重问题,而SERIALIZABLE会导致性能问题并增加死锁的机率
事务管理语句:
2,定义事务
MySQL默认的行为是在每条SQL语句执行后执行一个COMMIT语句,从而有效的将每条语句独立为一个事务。
在复杂的应用场景下这种方式就不能满足需求了。
为了打开事务,允许在COMMIT和ROLLBACK之前多条语句被执行,我们需要做以下两步:
1, 设置MySQL的autocommit属性为0,默认为1
2,使用START TRANSACTION语句显式的打开一个事务
如果已经打开一个事务,则SET autocommit=0不会起作用,因为START TRANSACTION会隐式的提交session中所有当前的更改,结束已有的事务,并打开一个新的事务。
使用SET AUTOCOMMIT语句的存储过程例子:
使用START TRANSACITON打开事务的例子:
通常COMMIT或ROLLBACK语句执行时才完成一个事务,但是有些DDL语句等会隐式触发COMMIT,所以应该在事务中尽可能少用或注意一下:
3,使用Savepoint
使用savepoint回滚难免有些性能消耗,一般可以用IF改写
savepoint的良好使用的场景之一是“嵌套事务”,你可能希望程序执行一个小的事务,但是不希望回滚外面更大的事务:
4,事务和锁
事务的ACID属性只能通过限制数据库的同步更改来实现,从而通过对修改数据加锁来实现。
直到事务触发COMMIT或ROLLBACK语句时锁才释放。
缺点是后面的事务必须等前面的事务完成才能开始执行,吞吐量随着等待锁释放的时间增长而递减。
MySQL/InnoDB通过行级锁来最小化锁竞争。这样修改同一table里其他行的数据没有限制,而且读数据可以始终没有等待。
可以在SELECT语句里使用FOR UPDATE或LOCK IN SHARE MODE语句来加上行级锁
FOR UPDATE会锁住该SELECT语句返回的行,其他SELECT和DML语句必须等待该SELECT语句所在的事务完成
LOCK IN SHARE MODE同FOR UPDATE,但是允许其他session的SELECT语句执行并允许获取SHARE MODE锁
死锁:
死锁发生于两个事务相互等待彼此释放锁的情景
当MySQL/InnoDB检查到死锁时,它会强制一个事务rollback并触发一条错误消息
对InnoDB而言,所选择的rollback的事务是完成工作最少的事务(所修改的行最少)
死锁在任何数据库系统里都可能发生,但是对MySQL/InnoDB这种行级锁数据库而言可能性相对较少。
可以通过使用一致的顺序来锁row或table以及让事务保持尽可能短来减少死锁的频率。
如果死锁不容易debug,你可以向你的程序中添加一些逻辑来处理死锁并重试事务,但这部分代码多了以后很难维护
所以,比较好的避免死锁的方式是在做任何修改之前按一定的顺序添加行级锁,这样就能避免死锁:
设置死锁ttl: innodb_lock_wait_timeout,默认为50秒
如果你在一个事务中混合使用InnoDB和非InnoDB表,则MySQL不能检测到死锁,此时会抛出“lock wait timeuot”1205错误
乐观所和悲观锁策略:
悲观锁:在读取数据时锁住那几行,其他对这几行的更新需要等到悲观锁结束时才能继续
乐观所:读取数据时不锁,更新时检查是否数据已经被更新过,如果是则取消当前更新
一般在悲观锁的等待时间过长而不能接受时我们才会选择乐观锁
悲观锁的例子:
乐观锁的例子:
5,事务设计指南
ACID:Atomic、Consistent、Isolated、Durable
存储程序提供了一个绝佳的机制来定义、封装和管理事务。
1,MySQL的事务支持
MySQL的事务支持不是绑定在MySQL服务器本身,而是与存储引擎相关:
MyISAM:不支持事务,用于只读程序提高性能 InnoDB:支持ACID事务、行级锁、并发 Berkeley DB:支持事务
隔离级别:
隔离级别决定了一个session中的事务可能对另一个session的影响、并发session对数据库的操作、一个session中所见数据的一致性
ANSI标准定义了4个隔离级别,MySQL的InnoDB都支持:
- READ UNCOMMITTED:最低级别的隔离,通常又称为dirty read,它允许一个事务读取还没commit的数据,这样可能会提高性能,但是dirty read可能不是我们想要的
- READ COMMITTED:在一个事务中只允许已经commit的记录可见,如果session中select还在查询中,另一session此时insert一条记录,则新添加的数据不可见
- REPEATABLE READ:在一个事务开始后,其他session对数据库的修改在本事务中不可见,直到本事务commit或rollback。在一个事务中重复select的结果一样,除非本事务中update数据库。
- SERIALIZABLE:最高级别的隔离,只允许事务串行执行。为了达到此目的,数据库会锁住每行已经读取的记录,其他session不能修改数据直到前一事务结束,事务commit或取消时才释放锁。
READ UNCOMMITTED:最低级别的隔离,通常又称为dirty read,它允许一个事务读取还没commit的数据,这样可能会提高性能,但是dirty read可能不是我们想要的 READ COMMITTED:在一个事务中只允许已经commit的记录可见,如果session中select还在查询中,另一session此时insert一条记录,则新添加的数据不可见 REPEATABLE READ:在一个事务开始后,其他session对数据库的修改在本事务中不可见,直到本事务commit或rollback。在一个事务中重复select的结果一样,除非本事务中update数据库。 SERIALIZABLE:最高级别的隔离,只允许事务串行执行。为了达到此目的,数据库会锁住每行已经读取的记录,其他session不能修改数据直到前一事务结束,事务commit或取消时才释放锁。
可以使用如下语句设置MySQL的session隔离级别:
- SET TRANSACTION ISOLATION LEVEL {READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SERIALIZABLE}
SET TRANSACTION ISOLATION LEVEL {READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SERIALIZABLE}
MySQL默认的隔离级别是REPEATABLE READ,在设置隔离级别为READ UNCOMMITTED或SERIALIZABLE时要小心,READ UNCOMMITTED会导致数据完整性的严重问题,而SERIALIZABLE会导致性能问题并增加死锁的机率
事务管理语句:
- START TRANSACTION:开始事务,autocommit设为0,如果已经有一个事务在运行,则会触发一个隐藏的COMMIT
- COMMIT:提交事务,保存更改,释放锁
- ROLLBACK:回滚本事务对数据库的所有更改,然后结束事务,释放锁
- SAVEPOINT savepoint_name:创建一个savepoint识别符来ROLLBACK TO SAVEPOINT
- ROLLBACK TO SAVEPOINT savepoint_name:回滚到从savepoint_name开始对数据库的所有更改,这样就允许回滚事务中的一部分,保证更改的一个子集被提交
- SET TRANSACTION:允许设置事务的隔离级别
- LOCK TABLES:允许显式的锁住一个或多个table,会隐式的关闭当前打开的事务,建议在执行LOCK TABLES语句之前显式的commit或rollback。我们一般所以一般在事务代码里不会使用LOCK TABLES
START TRANSACTION:开始事务,autocommit设为0,如果已经有一个事务在运行,则会触发一个隐藏的COMMIT COMMIT:提交事务,保存更改,释放锁 ROLLBACK:回滚本事务对数据库的所有更改,然后结束事务,释放锁 SAVEPOINT savepoint_name:创建一个savepoint识别符来ROLLBACK TO SAVEPOINT ROLLBACK TO SAVEPOINT savepoint_name:回滚到从savepoint_name开始对数据库的所有更改,这样就允许回滚事务中的一部分,保证更改的一个子集被提交 SET TRANSACTION:允许设置事务的隔离级别 LOCK TABLES:允许显式的锁住一个或多个table,会隐式的关闭当前打开的事务,建议在执行LOCK TABLES语句之前显式的commit或rollback。我们一般所以一般在事务代码里不会使用LOCK TABLES
2,定义事务
MySQL默认的行为是在每条SQL语句执行后执行一个COMMIT语句,从而有效的将每条语句独立为一个事务。
在复杂的应用场景下这种方式就不能满足需求了。
为了打开事务,允许在COMMIT和ROLLBACK之前多条语句被执行,我们需要做以下两步:
1, 设置MySQL的autocommit属性为0,默认为1
2,使用START TRANSACTION语句显式的打开一个事务
如果已经打开一个事务,则SET autocommit=0不会起作用,因为START TRANSACTION会隐式的提交session中所有当前的更改,结束已有的事务,并打开一个新的事务。
使用SET AUTOCOMMIT语句的存储过程例子:
- CREATE PROCEDURE tfer_funds
- (from_account int, to_account int, tfer_amount numeric(10,2))
- BEGIN
- SET autocommit=0;
- UPDATE account_balance SET balance=balance-tfer_amount WHERE account_id=from_account;
- UPDATE account_balance SET balance=balance+tfer_amount WHERE account_id=to_account;
- COMMIT;
- END;
CREATE PROCEDURE tfer_funds (from_account int, to_account int, tfer_amount numeric(10,2)) BEGIN SET autocommit=0; UPDATE account_balance SET balance=balance-tfer_amount WHERE account_id=from_account; UPDATE account_balance SET balance=balance+tfer_amount WHERE account_id=to_account; COMMIT; END;
使用START TRANSACITON打开事务的例子:
- CREATE PROCEDURE tfer_funds
- (from_account int, to_account int, tfer_amount numeric(10,2))
- BEGIN
- START TRANSACTION;
- UPDATE account_balance SET balance=balance-tfer_amount WHERE account_id=from_account;
- UPDATE account_balance SET balance=balance+tfer_amount WHERE account_id=to_account;
- COMMIT;
- END;
CREATE PROCEDURE tfer_funds (from_account int, to_account int, tfer_amount numeric(10,2)) BEGIN START TRANSACTION; UPDATE account_balance SET balance=balance-tfer_amount WHERE account_id=from_account; UPDATE account_balance SET balance=balance+tfer_amount WHERE account_id=to_account; COMMIT; END;
通常COMMIT或ROLLBACK语句执行时才完成一个事务,但是有些DDL语句等会隐式触发COMMIT,所以应该在事务中尽可能少用或注意一下:
- ALTER FUNCTION
- ALTER PROCEDURE
- ALTER TABLE
- BEGIN
- CREATE DATABASE
- CREATE FUNCTION
- CREATE INDEX
- CREATE PROCEDURE
- CREATE TABLE
- DROP DATABASE
- DROP FUNCTION
- DROP INDEX
- DROP PROCEDURE
- DROP TABLE
- UNLOCK TABLES
- LOAD MASTER DATA
- LOCK TABLES
- RENAME TABLE
- TRUNCATE TABLE
- SET AUTOCOMMIT=1
- START TRANSACTION
ALTER FUNCTION ALTER PROCEDURE ALTER TABLE BEGIN CREATE DATABASE CREATE FUNCTION CREATE INDEX CREATE PROCEDURE CREATE TABLE DROP DATABASE DROP FUNCTION DROP INDEX DROP PROCEDURE DROP TABLE UNLOCK TABLES LOAD MASTER DATA LOCK TABLES RENAME TABLE TRUNCATE TABLE SET AUTOCOMMIT=1 START TRANSACTION
3,使用Savepoint
使用savepoint回滚难免有些性能消耗,一般可以用IF改写
savepoint的良好使用的场景之一是“嵌套事务”,你可能希望程序执行一个小的事务,但是不希望回滚外面更大的事务:
- CREATE PROCEDURE nested_tfer_funds
- (in_from_acct INTEGER,
- in_to_acct INTEGER,
- in_tfer_amount DECIMAL(8,2))
- BEGIN
- DECLARE txn_error INTEGER DEFAULT 0;
- DECLARE CONTINUE HANDLER FOR SQLEXCEPTION BEGIN
- SET txn_error=1;
- END
- SAVEPINT savepint_tfer;
- UPDATE account_balance
- SET balance=balance-in_tfer_amount
- WHERE account_id=in_from_acct;
- IF txn_error THEN
- ROLLBACK TO savepoint_tfer;
- SELECT 'Transfer aborted';
- ELSE
- UPDATE account_balance
- SET balance=balance+in_tfer_amount
- WHERE account_id=in_to_acct;
- IF txn_error THEN
- ROLLBACK TO savepoint_tfer;
- SELECT 'Transfer aborted';
- END IF:
- END IF;
- END;
CREATE PROCEDURE nested_tfer_funds (in_from_acct INTEGER, in_to_acct INTEGER, in_tfer_amount DECIMAL(8,2)) BEGIN DECLARE txn_error INTEGER DEFAULT 0; DECLARE CONTINUE HANDLER FOR SQLEXCEPTION BEGIN SET txn_error=1; END SAVEPINT savepint_tfer; UPDATE account_balance SET balance=balance-in_tfer_amount WHERE account_id=in_from_acct; IF txn_error THEN ROLLBACK TO savepoint_tfer; SELECT 'Transfer aborted'; ELSE UPDATE account_balance SET balance=balance+in_tfer_amount WHERE account_id=in_to_acct; IF txn_error THEN ROLLBACK TO savepoint_tfer; SELECT 'Transfer aborted'; END IF: END IF; END;
4,事务和锁
事务的ACID属性只能通过限制数据库的同步更改来实现,从而通过对修改数据加锁来实现。
直到事务触发COMMIT或ROLLBACK语句时锁才释放。
缺点是后面的事务必须等前面的事务完成才能开始执行,吞吐量随着等待锁释放的时间增长而递减。
MySQL/InnoDB通过行级锁来最小化锁竞争。这样修改同一table里其他行的数据没有限制,而且读数据可以始终没有等待。
可以在SELECT语句里使用FOR UPDATE或LOCK IN SHARE MODE语句来加上行级锁
SELECT select_statement options [FOR UPDATE|LOCK IN SHARE MODE]
FOR UPDATE会锁住该SELECT语句返回的行,其他SELECT和DML语句必须等待该SELECT语句所在的事务完成
LOCK IN SHARE MODE同FOR UPDATE,但是允许其他session的SELECT语句执行并允许获取SHARE MODE锁
死锁:
死锁发生于两个事务相互等待彼此释放锁的情景
当MySQL/InnoDB检查到死锁时,它会强制一个事务rollback并触发一条错误消息
对InnoDB而言,所选择的rollback的事务是完成工作最少的事务(所修改的行最少)
- mysql > CALL tfer_funds(1,2,300);
- ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction
mysql > CALL tfer_funds(1,2,300); ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction
死锁在任何数据库系统里都可能发生,但是对MySQL/InnoDB这种行级锁数据库而言可能性相对较少。
可以通过使用一致的顺序来锁row或table以及让事务保持尽可能短来减少死锁的频率。
如果死锁不容易debug,你可以向你的程序中添加一些逻辑来处理死锁并重试事务,但这部分代码多了以后很难维护
所以,比较好的避免死锁的方式是在做任何修改之前按一定的顺序添加行级锁,这样就能避免死锁:
- CREATE PROCEDURE tfer_funds3
- (from_account INT, to_account INT, tfer_amount NUMERIC(10,2))
- BEGIN
- DECLARE local_account_id INT;
- DECLARE lock_cursor CURSOR FOR
- SELECT account_id
- FROM account_balance
- WHERE account_id IN (from_account, to_account)
- ORDER BY account_id
- FOR UPDATE;
- START TRANSACTION;
- OPEN lock_cursor;
- FETCH lock_cursor INTO local_account_id;
- UPDATE account_balance
- SET balance=balance-tfer_amount
- WHERE account_id=from_account;
- UPDATE account_balance
- SET balance=balance+tfer_amount
- WHERE account_id=to_account;
- CLOSE lock_cursor;
- COMMIT;
- END;
CREATE PROCEDURE tfer_funds3 (from_account INT, to_account INT, tfer_amount NUMERIC(10,2)) BEGIN DECLARE local_account_id INT; DECLARE lock_cursor CURSOR FOR SELECT account_id FROM account_balance WHERE account_id IN (from_account, to_account) ORDER BY account_id FOR UPDATE; START TRANSACTION; OPEN lock_cursor; FETCH lock_cursor INTO local_account_id; UPDATE account_balance SET balance=balance-tfer_amount WHERE account_id=from_account; UPDATE account_balance SET balance=balance+tfer_amount WHERE account_id=to_account; CLOSE lock_cursor; COMMIT; END;
设置死锁ttl: innodb_lock_wait_timeout,默认为50秒
如果你在一个事务中混合使用InnoDB和非InnoDB表,则MySQL不能检测到死锁,此时会抛出“lock wait timeuot”1205错误
乐观所和悲观锁策略:
悲观锁:在读取数据时锁住那几行,其他对这几行的更新需要等到悲观锁结束时才能继续
乐观所:读取数据时不锁,更新时检查是否数据已经被更新过,如果是则取消当前更新
一般在悲观锁的等待时间过长而不能接受时我们才会选择乐观锁
悲观锁的例子:
- CREATE PROCEDURE tfer_funds
- (from_account INT, to_account INT,tfer_amount NUMERIC(10,2),
- OUT status INT, OUT message VARCHAR(30))
- BEGIN
- DECLARE from_account_balance NUMERIC(10,2);
- START TRANSACTION;
- SELECT balance
- INTO from_account_balance
- FROM account_balance
- WHERE account_id=from_account
- FOR UPDATE;
- IF from_account_balance>=tfer_amount THEN
- UPDATE account_balance
- SET balance=balance-tfer_amount
- WHERE account_id=from_account;
- UPDATE account_balance
- SET balance=balance+tfer_amount
- WHERE account_id=to_account;
- COMMIT;
- SET status=0;
- SET message='OK';
- ELSE
- ROLLBACK;
- SET status=-1;
- SET message='Insufficient funds';
- END IF;
- END;
CREATE PROCEDURE tfer_funds (from_account INT, to_account INT,tfer_amount NUMERIC(10,2), OUT status INT, OUT message VARCHAR(30)) BEGIN DECLARE from_account_balance NUMERIC(10,2); START TRANSACTION; SELECT balance INTO from_account_balance FROM account_balance WHERE account_id=from_account FOR UPDATE; IF from_account_balance>=tfer_amount THEN UPDATE account_balance SET balance=balance-tfer_amount WHERE account_id=from_account; UPDATE account_balance SET balance=balance+tfer_amount WHERE account_id=to_account; COMMIT; SET status=0; SET message='OK'; ELSE ROLLBACK; SET status=-1; SET message='Insufficient funds'; END IF; END;
乐观锁的例子:
- CREATE PROCEDURE tfer_funds
- (from_account INT, to_account INT, tfer_amount NUMERIC(10,2),
- OUT status INT, OUT message VARCHAR(30) )
- BEGIN
- DECLARE from_account_balance NUMERIC(8,2);
- DECLARE from_account_balance2 NUMERIC(8,2);
- DECLARE from_account_timestamp1 TIMESTAMP;
- DECLARE from_account_timestamp2 TIMESTAMP;
- SELECT account_timestamp,balance
- INTO from_account_timestamp1,from_account_balance
- FROM account_balance
- WHERE account_id=from_account;
- IF (from_account_balance>=tfer_amount) THEN
- -- Here we perform some long running validation that
- -- might take a few minutes */
- CALL long_running_validation(from_account);
- START TRANSACTION;
- -- Make sure the account row has not been updated since
- -- our initial check
- SELECT account_timestamp, balance
- INTO from_account_timestamp2,from_account_balance2
- FROM account_balance
- WHERE account_id=from_account
- FOR UPDATE;
- IF (from_account_timestamp1 <> from_account_timestamp2 OR
- from_account_balance <> from_account_balance2) THEN
- ROLLBACK;
- SET status=-1;
- SET message=CONCAT("Transaction cancelled due to concurrent update",
- " of account" ,from_account);
- ELSE
- UPDATE account_balance
- SET balance=balance-tfer_amount
- WHERE account_id=from_account;
- UPDATE account_balance
- SET balance=balance+tfer_amount
- WHERE account_id=to_account;
- COMMIT;
- SET status=0;
- SET message="OK";
- END IF;
- ELSE
- ROLLBACK;
- SET status=-1;
- SET message="Insufficient funds";
- END IF;
- END$$
CREATE PROCEDURE tfer_funds (from_account INT, to_account INT, tfer_amount NUMERIC(10,2), OUT status INT, OUT message VARCHAR(30) ) BEGIN DECLARE from_account_balance NUMERIC(8,2); DECLARE from_account_balance2 NUMERIC(8,2); DECLARE from_account_timestamp1 TIMESTAMP; DECLARE from_account_timestamp2 TIMESTAMP; SELECT account_timestamp,balance INTO from_account_timestamp1,from_account_balance FROM account_balance WHERE account_id=from_account; IF (from_account_balance>=tfer_amount) THEN -- Here we perform some long running validation that -- might take a few minutes */ CALL long_running_validation(from_account); START TRANSACTION; -- Make sure the account row has not been updated since -- our initial check SELECT account_timestamp, balance INTO from_account_timestamp2,from_account_balance2 FROM account_balance WHERE account_id=from_account FOR UPDATE; IF (from_account_timestamp1 <> from_account_timestamp2 OR from_account_balance <> from_account_balance2) THEN ROLLBACK; SET status=-1; SET message=CONCAT("Transaction cancelled due to concurrent update", " of account" ,from_account); ELSE UPDATE account_balance SET balance=balance-tfer_amount WHERE account_id=from_account; UPDATE account_balance SET balance=balance+tfer_amount WHERE account_id=to_account; COMMIT; SET status=0; SET message="OK"; END IF; ELSE ROLLBACK; SET status=-1; SET message="Insufficient funds"; END IF; END$$
5,事务设计指南
- 1,保持事务短小
- 2,尽量避免事务中rollback
- 3,尽量避免savepoint
- 4,默认情况下,依赖于悲观锁
- 5,为吞吐量要求苛刻的事务考虑乐观锁
- 6,显示声明打开事务
- 7,锁的行越少越好,锁的时间越短越好
1,保持事务短小 2,尽量避免事务中rollback 3,尽量避免savepoint 4,默认情况下,依赖于悲观锁 5,为吞吐量要求苛刻的事务考虑乐观锁 6,显示声明打开事务 7,锁的行越少越好,锁的时间越短越好
发表评论
-
阿里开源Mysql分布式中间件:Cobar
2015-01-28 00:18 1069Cobar是阿里巴巴研发的关系型数据的分布式处理系统(Amoe ... -
由浅入深探究mysql索引结构原理、性能分析与优化
2015-01-28 00:13 758第一部分:基础知识 第 ... -
MySQL Explain 结果解读与实践
2015-01-27 22:33 846Explain 结果解读与实践 基于 MySQL 5.0.6 ... -
MySQL 高可用架构之MMM - yayun
2015-01-20 00:09 809简介 MMM(Master-Master replicati ... -
理解MySQL——索引与优化
2015-01-09 15:23 641写在前面:索引对查询的速度有着至关重要的影响,理解索引也是进 ... -
B树、B-树、B+树、B*树
2015-01-09 15:10 704B树 即二叉搜索树: 1.所 ... -
MySQL NDB 6.3.20集群安装
2014-10-19 10:49 948引言: 本文会先对MySQ ... -
sphinx的配置和管理
2013-10-16 14:38 713Sphinx增量索引(转) 在实际应用中往往有这么一 ... -
微博数据库设计
2013-06-14 09:27 0部分功能建表设计 Use ... -
MySQL STRAIGHT_JOIN 与 NATURAL JOIN
2013-03-12 14:10 1190MySQL STRAIGHT_JOIN STRAIGHT_ ... -
MySQL的四种不同查询的分析
2013-03-02 09:42 01.前置条件: 本次是基于小数据量,且数据块在一个页中的最 ... -
MySQL Variable解读
2012-12-07 14:36 2164说明:具体参数还是要很对应版本对应,这是dba必须要 ... -
MySQL DELAY_KEY_WRITE(在mysql插入大数据量时可以关闭索引的选项)
2012-12-07 14:27 0mysql插入索引太慢 加参 ... -
mysql 的explain解析
2012-11-16 15:43 0在 explain的帮助下,您 ... -
java execute、executeQuery和executeUpdate之间的区别
2012-11-16 13:51 1071在用纯JSP做一个页面报警功能的时候习惯性的用executeQ ... -
MySQL分区表
2012-11-16 10:46 929查看分区情况 点击(此处)折叠或打开 ... -
Linux启用MySQL的InnoDB引擎[转]
2012-10-24 23:09 0前几天公司的一个项目组的同事反应说公司内部的一台Linux服务 ... -
源码安装Mysql,补装innodb引擎方法
2012-10-24 23:03 933首先确定,在mysql的'plugin_dir'下有ha_ ... -
MYSQL使用.frm恢复数据表结构的实现方法
2012-10-16 23:06 969我们都知道当我们建立数据表(innodb或myisam)时,会 ... -
史上最详细MySQL5.5复制配置步骤,与以前版本的有所不同[转]
2012-05-21 12:53 979操作系统:CentOS 5.8 MySQL版本:5.5 ...
相关推荐
什么情况适合用存储过程? 当多个用不同语言开发的应用程序或不同平台的应用程序需要去执行相同的数据库操作. (避免为各个程序都开发相同的功能) 安全性要求较高时,使用存储程序和...MySql存储过程与事务处理教学PPT
总的来说,通过学习“mysql经典教程+mysql存储过程讲解”,你不仅可以掌握MySQL的基础操作,还能深入了解如何利用存储过程、触发器和游标来实现更复杂的数据管理策略。这将有助于你成为一名更高效的数据库管理员或...
MySQL存储过程是数据库管理系统中的一种重要功能,它允许开发者预编译一系列的SQL语句,形成一个可重复使用的代码块,以提高数据处理的效率和应用程序的性能。在这个"MySQL存储过程学习"的主题中,我们将深入探讨...
MySQL存储过程是数据库管理系统中的一种重要功能,它允许开发者预编译一系列的SQL语句,形成一个可重复执行的单元,极大地提高了数据库操作的效率和便捷性。在MySQL中,存储过程可以包含复杂的业务逻辑,比如条件...
MySQL是目前最流行的开源关系型数据库管理系统之一,它提供了丰富的数据库高级特性,比如存储过程、触发器和事务管理。这些特性增强了数据库的交互性、安全性和性能。 一、存储过程 存储过程是一组为了完成特定...
MySQL存储过程是数据库管理系统中的一种重要功能,它允许开发者预编译一组SQL语句并封装成一个可重复使用的对象。这种技术在处理复杂的业务逻辑、提高数据操作效率以及减少网络传输时非常有用。本文件“MySQL存储...
MySQL存储过程是数据库管理系统中的一种重要功能,它允许开发者预编译一组SQL语句并封装成一个可重复使用的对象。这个经典教程旨在深入探讨存储过程的各个方面,帮助读者掌握这一强大的数据库编程工具。 1. **存储...
MySQL存储过程编程是数据库应用开发中的一个重要环节,它可以帮助开发者将一系列的数据库操作封装起来,以提高程序的可维护性和运行效率。在MySQL 5.0及以上版本中,存储过程、函数和触发器的支持为数据库提供了更...
存储过程文档--MySQL 存储过程是 MySQL 中的一个强大功能,它允许用户预先将常用的或复杂的工作写入 SQL 语句,并将其存储起来,以便在以后的数据库操作中可以快速调用和执行。存储过程可以提高数据库的执行速度,...
### MySQL存储过程基础知识点 #### 1. 存储过程的定义和示例 存储过程是存储在MySQL服务器上的预编译的SQL代码段,它能够接受参数、执行一系列的SQL语句和流程控制语句。存储过程可以提高数据库操作的效率,同时...
1,MySQL的事务支持 1)MySQL的事务支持不是绑定在MySQL服务器本身,而是与存储引擎相关: Sql代码 代码如下: MyISAM:不支持事务,用于只读程序提高性能 InnoDB:支持ACID事务、行级锁、并发 Berkeley DB:支持...
MySQL存储过程是数据库管理系统中的一个重要组成部分,它允许程序员和数据库管理员预先定义一组SQL语句,并将其打包成一个可重用的单元。这个过程可以包含多种SQL操作,如INSERT、UPDATE、SELECT等,以及流程控制...
MySQL存储过程是数据库管理系统中的一种重要功能,它允许开发者预定义一组SQL语句,并将其封装成一个可重复使用的单元。这个电子书显然专注于探讨MySQL存储过程的各个方面,为学习者提供了一个深入理解、创建和使用...
MySQL存储过程是数据库管理系统中的一种预编译的代码集合,它允许开发者定义一系列的SQL语句,形成一个可重用的程序单元。在MySQL中,存储过程可以接收参数,执行复杂的逻辑,甚至可以包含控制流语句,如条件判断和...
在MySQL数据库中,存储过程是一种预编译的SQL语句集合,它可以封装一系列的操作,用于执行复杂的业务逻辑。创建存储过程并循环添加记录是数据库管理中的常见任务,尤其是在需要批量插入数据时。以下将详细解释如何在...
通常,存储过程的代码会包含输入参数、查询、更新语句以及事务管理语句。通过分析这部分代码,你可以学习到如何在实际项目中设计和实现类似的存储过程。 总的来说,银行转账存储过程是一个综合性的数据库操作示例,...
同时,`mysql存储过程教程.pdf`很可能是一个详细的指南,涵盖了存储过程的基础概念、语法、高级特性以及实例。通过阅读这份教程,读者可以学习如何创建、修改、删除存储过程,理解如何在存储过程中使用变量、游标、...