索引

<转>MySQL性能调优的10个方法

江枫思渺然 提交于 2020-03-18 14:30:50
文章原地址: http://mp.weixin.qq.com/s/oRXJRz_Y5drmIrcbxSKOcw 1. 选择合适的存储引擎: InnoDB 除非你的数据表使用来做只读或者全文检索 (相信现在提到全文检索,没人会用 MYSQL 了),你应该默认选择 InnoDB 。 你自己在测试的时候可能会发现 MyISAM 比 InnoDB 速度快,这是因为: MyISAM 只缓存索引,而 InnoDB 缓存数据和索引,MyISAM 不支持事务。 但是 如果你使用 innodb_flush_log_at_trx_commit = 2 可以获得接近的读取性能 (相差百倍) 。 1.1 如何将现有的 MyISAM 数据库转换为 InnoDB: mysql -u [USER_NAME] -p -e "SHOW TABLES IN [DATABASE_NAME];" | tail -n +2 | xargs -I '{}' echo "ALTER TABLE {} ENGINE=InnoDB;" > alter_table.sql perl -p -i -e 's/(search_[a-z_]+ ENGINE=)InnoDB//1MyISAM/g' alter_table.sql mysql -u [USER_NAME] -p [DATABASE_NAME] < alter_table

sqlite索引的原理

喜你入骨 提交于 2020-03-18 13:59:12
引言 这篇文章 ,里面讲到对于一个41G大小、包含百万条记录的数据库进行查询操作,如果利用了索引,可以把操作耗时从37s降到0.2s。 那么什么是索引呢?利用索引可以加快数据库查询操作的原理是什么呢? 索引的基本原理 数据库提供了一种持久化的数据存储方式,从数据库中查询数据库是一个基本的操作,查询操作的效率是很重要的。 对于查询操作来说,如果被查询的数据已某种方式组织起来,那么查询操作的效率会极大提高。 在数据库中,一条记录会有很多列。如果把这些记录按照列Col1以某种数据结构组织起来,那么列Col2一定是乱序的。 因此,数据库在原始数据之外,维护了满足特定查找算法的数据结构,指向原始数据,称之为 索引 。 举例来说,在下面的图中,数据库有两列Col1、Col2。在存储时,按照列Col1组织各行,比如Col1已二叉树方式组织。如果查找col1中的某一个值,利用二叉树进行二分查找,不需要遍历整个数据库。 这样一来列Col2就是乱序的。为了解决这个问题,为Col2建立了索引,即把Col2也按照某种数据结构(这里是二叉树)组织起来。这样子查找列Col2时只需要进行二分查找即可。  索引的实现 由于数据库是存储在磁盘上的,因此实现索引用的数据结构会存储在磁盘上。磁盘的IO是需要注意的问题。 二叉树 二叉树是一种经典的数据结构,但是并不适合进行数据库索引。

MySQL-事物、索引和视图

懵懂的女人 提交于 2020-03-18 13:56:23
1.视图 对于复杂的语句,多次使用时,要维护是一件很麻烦的事情。 解救的办法:就是定义一个视图,相当于编程语言中的封装。 定义视图 语法如下: create view v_student as select * from student where name = zhangsan; 调用: select * from v_student; 2.事物 当一件事情需要多个sql完成时,如果其中的某条语句出错,则希望整个操作都退回。 主要作用是保证命令的完整性。 2.1事物的四大特性 原子性:事物中的全部操作在数据库中是不可分割的,要么全部完成,要么都不完成。 一致性:几个并行执行的任务,其执行结果必须与按照某一顺序执行的结果一致。 隔离性:事物的执行不受其他事物的干扰,事物执行的结果对其他事物必须是透明的。 持久性:对于已经提交的事物,系统必须保证事物对该数据库的改变不曾丢失,即使数据库出现故障。 2.2 使用事物的情况 数据被更改时,包括insert、updata、del等操作进行时使用事物。 要求:表的类型必须是innodb或者bdb类型,才可以使用事物。 查看表的类型:show create table students; 修改表的类型:alter table 表名称 engine=innodb; 事物语句: 开启:begin; 提交:commit; 回滚:rollback; 2

深入理解MySQL索引

做~自己de王妃 提交于 2020-03-18 13:26:59
前言 当提到MySQL数据库的时候,我们的脑海里会想起几个关键字:索引、事务、数据库锁等等,索引是MySQL的灵魂,是平时进行查询时的利器,也是面试中的重中之重。 可能你了解索引的底层是b+树,会加快查询,也会在表中建立索引,但这是远远不够的,这里列举几个索引常见的面试题: 1、索引为什么要用b+树这种数据结构? 2、聚集索引和非聚集索引的区别? 3、索引什么时候会失效,最左匹配原则是什么? 当遇到这些问题的时候,可能会发现自己对索引还是一知半解,今天我们一起学习MySQL的索引。 一、一条查询语句是如何执行的 首先来看在MySQL数据库中,一条查询语句是如何执行的,索引出现在哪个环节,起到了什么作用。 1.1 应用程序发现SQL到服务端 当执行SQL语句时,应用程序会连接到相应的数据库服务器,然后服务器对SQL进行处理。 1.2 查询缓存 接着数据库服务器会先去查询是否有该SQL语句的缓存,key是查询的语句,value是查询的结果。如果你的查询能够直接命中,就会直接从缓存中拿出value来返回客户端。 注:查询不会被解析、不会生成执行计划、不会被执行。 1.3 查询优化处理,生成执行计划 如果没有命中缓存,则开始第三步。 解析SQL:生成解析树,验证关键字如select,where,left join 等)是否正确。 预处理:进一步检查解析树是否合法,如检查数据表和列是否存在

联合索引和单列索引

心已入冬 提交于 2020-03-18 06:12:27
1.  首先对于单列索引来说,它比较适合建在重读度低的列上。 2.  联合索引又叫复合索引,它是对多个字段同时建立的索引(有顺序,ABC,ACB是完全不同的两种联合索引)。对于复合索引:Mysql从左到右的使用索引中的字段,一个查询可以只使用索引中的一部份,但只能是最左侧部分。例如索引是key index (a,b,c). 建立这样的索引相当于建立了索引a、ab、abc三个索引。可以支持a | a,b| a,b,c 3种组合进行查找,但不支持 b,c进行查找 .当最左侧字段是常量引用时,索引就十分有效。注意:索引列越多通过索引筛选出的数据越少。 3.  覆盖(动词)索引:同样的有联合索引(a,b,c),如果有如下的sql: select a,b,c from table where a=xxx and b = xxx。那么MySQL可以直接通过遍历索引取得数据,而无需读表,这减少了很多的随机io操作。 4.  使用时注意什么       1.单个索引需要注意的事项,组合索引全部通用。比如索引列不要参与计算啊、or的两侧要么都索引列,要么都不是索引列啊、模糊匹配的时候%不要在头部啦等等       2.最左匹配原则。(A,B,C) 这样3列,mysql会首先匹配A,然后再B,C. 如果用(B,C)这样的数据来检索的话,就会找不到A使得索引失效。如果使用(A,C)这样的数据来检索的话

Python列表和元祖

|▌冷眼眸甩不掉的悲伤 提交于 2020-03-18 06:05:14
Python的数据结构有 序列和容器(容器包含序列、映射、集合) Python包含6种内建的序列:列表、元祖、字符串、Unicode字符串、buffer对象、xrange对象。 最基本的数据结构是序列(元祖和列表),序列中所有元素都是有编号的,元素的位置称为索引,第一个索引得失0,第二个索引是1...,最后一个索引为-1 序列类型转换的工厂函数: list(iter)把可迭代对象转换为列表 str(obj)把对象转换成字符串 unicode(obj) basestring() tuple(iter)把可迭代对象转换成一个元祖对象 通用序列操作: 通用操作 说明 例子 索引 字符串字面值能够直接使用索引 变量引用使用索引 'Hello'[1] moth[1] 分片 跟索引类似 可以置空最后/第一个的索引 可以是负数,从结尾开始计数 加入步长 tag[9:30] tag[2:] tag[-3:-1] tag[::-2] 相加 相同类型的序列才能进行连接操作 [1,2,3]+[4,5] 输出[1,2,3,4,5] 乘法 原来的序列将被重复x次 'python'*5 [10]*3 成员资格 元素 in 序列,返回布尔值 'w' in 'rw' 'users' in ['mlh','users'] 长度 内建函数 len(numbers) max/min 内建函数 max(2,3,4) 比较

程序员看了都要收藏系列:Mysql进阶知识干货笔记!

房东的猫 提交于 2020-03-17 22:54:17
一、SQL执行顺序以及常见SQL的join查询 sql执行顺序 : 手写 SELECT DISTINCT <select_list> FROM <left table> <join type> JOIN <right_table> ON <join_codition> WHERE <where_condition> HAVING <having_condition> ORDER BY < order_by_condition> LIMIT < limit number> 机读顺序 1 FROM <left_table> 2 ON <join_condition> 3 <join_type> JOIN <right_table> 4 WHERE <where_condition> 5 GROUP BY <group by_list> 6 HAVING <having_condition> 7 SELECT 8 DISTINCT <select_list> 9 ORDER BY <order_by_condition> 10 LIMIT <limit_number> sql机器执行顺序 七种join关系 二、索引 1、什么是索引 索引是帮助MYSQL高效获取数据的数据结构-->排好序的快速查找数据结构 我们平时所说的索引,没有特别指明,都是指B树(多路搜索树,不一定是二叉)

MySQL中InnoDB和MyISAM引擎的对比

心已入冬 提交于 2020-03-17 19:05:34
目录 索引对比 锁对比 事务对比 并发 全文索引对比 外键 其他 一.索引对比 1.B+树概念 我们这里关注B+树的两个特性: 叶子节点包含数据data(data并不特指数据库中的某一行数据,也可以是某个数值,指针等) 叶子节点均在同一层,且每个节点均可以直接找到上一个或者下一个节点(双向指针,比常规的B+树多了一个指向上一个的指针) 2.Innodb 以用户表为例, id 为主键,另外name存在索引 idx_name : CREATE TABLE `t_user` ( `id` bigint, `name` varchar(10), `age` int, PRIMARY KEY (`id`), KEY `idx_name` (`name`) ); 插入数据: insert into t_user (id,`name`,age) values (1,'n7',10), (2,'n6',20), (3,'n5',30), (4,'n4',40), (5,'n3',50), (6,'n2',60), (7,'n1',70) ①聚簇索引(聚集索引) 聚簇索引:行数据与键值(主键)紧凑地存储在一起; InnoDB中表现为:B+树叶子节点的data用于存放 行数据 (包含主键值、其他列数据、回滚指针、事务id等),物理上索引数据与行数据都放在同一个文件中( .ibd ) 如果没有定义主键

ClickHouse 概念整理

我怕爱的太早我们不能终老 提交于 2020-03-17 18:59:36
什么是ClickHouse? 毛子开源的一个列式存储数据库(DBMS), 主要用于OLAP, 能使用SQL查询实时生成分析数据报告。 可以类比HBase 数据类型 与其他框架比较 MySQL Hive ClickHouse byte TINYINT Int8 short SMALLINT Int16 int INT Int32 long BIGINT Int64 varchar STRING String timestamp TIMESTAMP DateTime float FLOAT Float32 double DOUBLE Float64 boolean BOOLEAN 无 整形 固定长度的整形, 包括有符号整型或无符号整型。 整型范围 (-2 n-1 , 2 n-1 -1) 无符号整型范围 (0 ~ 2 n -1) 浮点型(不建议用, 有精度损失问题) Float32 Float64 布尔型 没有单独的类型来存储布尔值。可以使用 UInt8 类型, 取值限制为 0 或 1。 字符串 String 字符串可以是任意长度的。它可以包含任意的字节集, 包含空字节。 FixedString(N) 固定长度 N 的字符串, N必须是严格的正自然数。 当服务端读取长度小于 N 的字符串时, 通过在字符串末尾添加空字节来达到 N 字节长度。 当服务端读取长度大鱼 N 的字符串时,

Facebook 如何管理150亿张照片

非 Y 不嫁゛ 提交于 2020-03-17 15:20:07
某厂面试归来,发现自己落伍了!>>> Facebook 的照片分享很受欢迎,迄今,Facebook 用户已经上传了150亿张照片,加上缩略图,总容量超过1.5PB,而每周新增的照片为2亿2000万张,约25TB,高峰期,Facebook 每秒处理55万张照片,这些数字让如何管理这些数据成为一个巨大的挑战。本文由 Facebook 工程师撰写,讲述了他们是如何管理这些照片的。 旧的 NFS 照片架构 老的照片系统架构分以下几个层: # 上传层接收用户上传的照片并保存在 NFS 存储层。 # 照片服务层接收 HTTP 请求并从 NFS 存储层输出照片。 # NFS存储层建立在商业存储系统之上。 因为每张照片都以文件形式单独存储,这样庞大的照片量导致非常庞大的元数据规模,超过了 NFS 存储层的缓存上限,导致每次招聘请求会上传都包含多次I/O操作。庞大的元数据成为整个照片架构的瓶颈。这就是为什么 Facebook 主要依赖 CDN 的原因。为了解决这些问题,他们做了两项优化: # Cachr: 一个缓存服务器,缓存 Facebook 的小尺寸用户资料照片。 # NFS文件句柄缓存:部署在照片输出层,以降低 NFS 存储层的元数据开销。 新的 Haystack 照片架构 新的照片架构将输出层和存储层合并为一个物理层,建立在一个基于 HTTP 的照片服务器上,照片存储在一个叫做