InnoDB

MySql之建表思想

一笑奈何 提交于 2020-12-16 11:02:55
1.数据库主表、从表、主键、外键 (1)主键:一般情况下,满足第一范式的表都有一个主键Primary key,用于唯一标识的数据库表中的一个字段。 外键:外键是相对于数据库设计中的参考完整性而言,它与主键之间是彼此依赖的关系。假设现在有两个表,产品分类表ProductCategory(主键c_id)和产品表Product(主键p_id),每类产品都属于一个分类。那么如果产品信息表肯定需要参考产品分类表进行定义。因为如果没有产品分类表,又何谈产品分类呢。所以产品信息表Product(从表)需要引用ProductCategory(主表)中的主键CategoryId 进行产品分类定义,Product表中引用c_id的字段就是外键。 (从表的外键与主表的主键相对应以此用来和主表相关联或者说主表的主键作为从表的外键以此来和从表相关联) 主表:被作为外键引用的表。 从表:有外键引用的表。 外键可以为空值(除了SQLServer等一些数据库),但如果有值的话一定是你参照的那个主表中的主键值。换句话说,从表需要用到主表的属性,没有主表就没有从表。 当删除数据时 : delete cascade (级联删除):如果主表中的一个主键被删除了,那么引用该主键的从表中的所有记录也被删除。 restrict (删除限制):如果主表中的一个主键被删除时,当从表中仍有外键引用这个主键时

mysql性能优化(三)- 事务控制

 ̄綄美尐妖づ 提交于 2020-12-16 10:41:17
1、Innodb引擎对隔离级别的支持程度 事务隔离级别 脏读 不可重复读 幻读 未提交读(Read Uncommited) 可能 可能 可能 已提交读(Read Commited) 不可能 可能 可能 可重复读(Repeated Read) 不可能 不可能 对Innodb不可能 串行化(Serializable) 不可能 不可能 不可能 隔离级别到底如何实现的呢?锁、MVCC 2、理解表锁、行锁 锁是用于管理不同事务对共享资源的并发访问 表锁与行锁的区别: 锁定粒度:表锁 > 行锁 加锁效率:表锁 > 行锁 冲突概率:表锁 > 行锁 并发性能:表锁 < 行锁 InnoDB存储引擎支持行锁和表锁(另类的行锁) 3、MySql InnoDB锁类型 共享锁(行锁):Shared Locks 排它锁(行锁):Exclusive Locks 意向锁共享锁(表锁):Intention Shared Locks 意向锁排它锁(表锁):Intention Exclusive Locks 自增锁:AUTO-INC Locks a、行锁的算法 记录锁 Record Locks 间隙锁 Gap Locks 临键锁 Next-key Locks b、共享锁(Shared Locks)VS 排它锁(Exclusive Locks) 共享锁:又称为读锁,简称S锁,顾名思义

mysql中key 、primary key 、unique key 与index区别

半腔热情 提交于 2020-12-16 07:16:01
索引被用来快速找出在一个列上用一特定值的行。没有索引,MySQL不得不首先以第一条记录开始并然后读完整个表直到它找出相关的行。 表越大,花费时间越多。如果表对于查询的列有一个索引,MySQL能快速到达一个位置去搜寻到数据文件的中间,没有必要考虑所有数据。 如果一个表有1000行,这比顺序读取至少快100倍。注意你需要存取几乎所有1000行,它较快的顺序读取,因为此时我们避免磁盘寻道。 所有的MySQL索引(PRIMARY、UNIQUE和INDEX)在B树中存储。字符串是自动地压缩前缀和结尾空间。 索引用于: 快速找出匹配一个WHERE子句的行; 当执行联结时,从其他表检索行; 对特定的索引列找出MAX()或MIN()值; 如果排序或分组在一个可用键的最左面前缀上进行(例如,ORDER BY key_part_1,key_part_2),排序或分组一个表。 如果所有键值部分跟随DESC,键以倒序被读取。 在一些情况中,一个查询能被优化来检索值,不用咨询数据文件。 如果对某些表的所有使用的列是数字型的并且构成某些键的最左面前缀,为了更快,值可以从索引树被检索出来。 ————————————————————————————————————————————————————————————————————————————— 下面是建表的语句: [sql] view plain copy

MySQL Bug剖析之Slave节点并行复制死锁

让人想犯罪 __ 提交于 2020-12-16 07:14:59
此文已由作者温正湖授权网易云社区发布。 欢迎访问 网易云社区 ,了解更多网易技术产品运营经验。 有天一早,DBA同学就找上来了,说有个DDB集群下的RDS实例Slave节点(从库)死锁了,请求支援。说实话,一大早就遇到死锁这种棘手的问题,我的内心是奔溃的。不过万幸的是,DBA说这个实例还未正式上线,处于上线前压测阶段。这么一来,至少现场可以一直保持着。方便定位问题。那么,是什么问题呢,不卖关子,直接上图: 这是show processlist的结果。可以看到有一大坨的连接,基本上都是权限操作相关的语句,全都卡在“waiting for table level lock”上。还有几个复制管理操作,比如stop slave,也卡住了。这密密麻麻一大堆,看得都烦。还是得从这些连接里面挖掘出少数有用的信息。所以登上实例的mysql客户端捋下才是王道。先看看有没有锁相关的直接信息: show engine innodb status\G ------------ TRANSACTIONS ------------ Trx id counter 6506046 Purge done for trx's n:o < 6506038 undo n:o < 0 state: running but idle History list length 2057 LIST OF TRANSACTIONS

mysql中key 、primary key 、unique key 与index区别

*爱你&永不变心* 提交于 2020-12-16 06:58:09
一、key与primary key区别 CREATE TABLE wh_logrecord ( logrecord_id int(11) NOT NULL auto_increment, user_name varchar(100) default NULL, operation_time datetime default NULL, logrecord_operation varchar(100) default NULL, PRIMARY KEY (logrecord_id), KEY wh_logrecord_user_name (user_name) ) 解析: KEY wh_logrecord_user_name (user_name) 本表的user_name字段与wh_logrecord_user_name表user_name字段建立外键 括号外是建立外键的对应表,括号内是对应字段 类似还有 KEY user(userid) 当然,key未必都是外键 总结: Key是索引约束,对表中字段进行约束索引的,都是通过primary foreign unique等创建的。常见有foreign key,外键关联用的。 KEY forum (status,type,displayorder) # 是多列索引(键) KEY tid (tid) # 是单列索引(键)。 如建表时:

一条简单的更新语句,MySQL是如何加锁的?

假如想象 提交于 2020-12-16 06:54:52
看如下一条sql语句: #tableT(idint,namevarchar(20))deletefromTwhereid=10; MySQL在执行的过程中,是如何加锁呢? 再看下面这条语句: select*fromTwhereid=10; 那这条语句呢?其实这其中包含太多知识点了。要回答这两个问题,首先需要了解一些知识。 相关知识介绍 多版本并发控制 在MySQL默认存储引擎InnoDB中,实现的是基于多版本的并发控制协议——MVCC(Multi-Version Concurrency Control)(注:与MVVC相对的,是基于锁的并发控制,Lock-Based Concurrency Control)。 其中MVCC最大的好处是:读不加锁,读写不冲突。在读多写少的OLTP应用中,读写不冲突是非常重要的,极大的提高了系统的并发性能,在现阶段,几乎所有的RDBMS,都支持MVCC。其实,MVCC就一句话总结:同一份数据临时保存多个版本的一种方式,进而实现并发控制。 当前读和快照读 在MVCC并发控制中,读操作可以分为两类:快照读与当前读。 快照读(简单的select操作):读取的是记录中的可见版本(可能是历史版本),不用加锁。这你就知道第二个问题的答案了吧。 当前读(特殊的select操作、insert、delete和update):读取的是记录中最新版本

一条简单的更新语句,MySQL是如何加锁的?

冷暖自知 提交于 2020-12-16 06:54:40
如下一条sql语句: [SQL] 纯文本查看 复制代码 ? # table T (id int , name varchar (20)) delete from T where id = 10; MySQL在执行的过程中,是如何加锁呢? 在看下面这条语句: [SQL] 纯文本查看 复制代码 ? select * from T where id = 10; 那这条语句呢?其实这其中包含太多知识点了。要回答这两个问题,首先需要了解一些知识。 相关知识介绍 多版本并发控制 在MySQL默认存储引擎InnoDB中,实现的是基于多版本的并发控制协议——MVCC(Multi-Version Concurrency Control)(注:与MVVC相对的,是基于锁的并发控制,Lock-Based Concurrency Control)。其中MVCC最大的好处是:读不加锁,读写不冲突。在读多写少的OLTP应用中,读写不冲突是非常重要的,极大的提高了系统的并发性能,在现阶段,几乎所有的RDBMS,都支持MVCC。其实,MVCC就一句话总结:同一份数据临时保存多个版本的一种方式,进而实现并发控制。 当前读和快照读 在MVCC并发控制中,读操作可以分为两类:快照读与当前读。 快照读(简单的select操作):读取的是记录中的可见版本(可能是历史版本),不用加锁。这你就知道第二个问题的答案了吧。 当前读

SQL 技巧:KEY INDEX UNIQUE PRIMARY FULLTEXT差异性和相似性

此生再无相见时 提交于 2020-12-16 02:58:02
分析项 primary: 必须唯一,是一个索引,是(可能是)物理索引,每个表只能有一个。 unique: 正如它所说。 具有该值的元组的行不能超过一个。 请注意,由于唯一键可以超过一列,这并不一定意味着索引中的每个单独列都是唯一的,但是这些列中值的每种组合都是唯一的。 index: 如果它不是主要的或唯一的,则不会约束插入表中的值,但确实可以更有效地查找它们。 FULLTEXT: 索引的一种更专业的形式,允许全文搜索。 将其视为(本质上)为指定列中的每个“单词”创建一个“索引”。 差异性 KEY或INDEX 是指普通的非唯一索引。允许使用索引的非唯一值,因此索引的所有列中可能包含具有相同值的行。这些索引不会对您的数据施加任何限制,因此仅用于确保某些查询可以快速运行。 UNIQUE引用索引 ,其中索引的所有行都必须是唯一的。也就是说,对于该索引中的所有列,同一行可能不具有与另一行相同的非NULL值。除了用于加快查询速度外,UNIQUE索引还可用于对数据施加约束,因为数据库系统不允许在插入或更新数据时破坏此不同值规则。 您的数据库系统可能允许将UNIQUE索引应用于允许NULL值的列,在这种情况下,如果两行都包含NULL值,则允许两行相同(此处的理由是NULL被视为不等于其自身)。但是,根据您的应用程序,您可能会发现这种情况不受欢迎:如果希望防止这种情况

How to make MySQL use functional index on a datetime column?

我的未来我决定 提交于 2020-12-16 02:23:05
问题 Say I'm running MySQL 8 with a table data containing about 1M rows. And I want to filter a datetime column on date a range (using a date index). CREATE TABLE `data` ( `rowId` int NOT NULL AUTO_INCREMENT, `data` json NOT NULL, `created` DATETIME NOT NULL, -- <-- datetime column for a date index `created_date` DATE AS (cast(`created` as date)) NOT NULL, -- <-- generated date column PRIMARY KEY (`rowId`), INDEX (`created`), -- <-- datetime index w/ cardinality ~ 1M INDEX (`created_date`) -- <--

How to make MySQL use functional index on a datetime column?

帅比萌擦擦* 提交于 2020-12-16 02:19:24
问题 Say I'm running MySQL 8 with a table data containing about 1M rows. And I want to filter a datetime column on date a range (using a date index). CREATE TABLE `data` ( `rowId` int NOT NULL AUTO_INCREMENT, `data` json NOT NULL, `created` DATETIME NOT NULL, -- <-- datetime column for a date index `created_date` DATE AS (cast(`created` as date)) NOT NULL, -- <-- generated date column PRIMARY KEY (`rowId`), INDEX (`created`), -- <-- datetime index w/ cardinality ~ 1M INDEX (`created_date`) -- <--