前言 一直以来,对于搜索时模糊匹配的优化一直是个让人头疼的问题,好在强大pgsql提供了优化方案,下面就来简单谈一谈如何通过索引来优化模糊匹配 案例 我们有一张千万级数据的检查报告表,需要通过检查报告来模糊搜索某个条件,我们先创建如下索引: CREATE INDEX lab_report_report_name_index ON lab_report USING btree (report_name); 然后搜个简单的模糊匹配条件如 LIKE "血常规%",可以发现查询计划生成如下,索

1.索引类型: 1.1B-tree索引: 注:名叫btree索引,大的方面看,都用的是平衡树,但具体的实现上,各引擎稍有不同,比如,严格的说,NDB引擎,使用的是T-tree,但是在MyISAM,Innodb中,默认的使用的是B-tree索引 但我们抽象一下---B-tree系统,可以理解成为“排好序的快速查找结构” 1.2hash索引 在memory表中,默认的是hash索引,hash的理论查询时间复杂度为O(1) 那为啥hash的查找如此的搞笑,为什么都不用hash索引? 答:1.hash函

前缀索引,是指对于VARCHAR/TEXT/BLOB类型的字段建立索引时一般都会选择前N个字符作为索引.索引很长的字符列,会让索引变得大且慢.索引开始的部分字符,这样可以大大节约索引空间,从而提高索引效率,但这样也会降低索引的选择性.索引的选择性是指不重复的索引值(也称为基数,cardinality)和数据表的记录总数的比值. 计算公式:SELECT COUNT(DISTINCT(a))/COUNT(*) FROM table1; SELECT COUNT(DISTINCT(LEFT((UUID

有时需要索引很长的字符列,它会使索引变大而且变慢.一个策略就是模拟哈希索引.但是有时这也不够好,那? 通常可以索引开始的几个字符,而不是全部值,以节约空间并得到好的性能.这使索引需要的空间变小,但是也会降低选择性.索引选择性是不重复的索引值 和表中所有行的比值.高选择性的索引有好处,因为它使mysql在查找匹配的时候可以过波掉更多的行.唯一索引的选择率为1,为最佳值. 如果索引BLOG和TEXT列,或者很长的varchar列,就必须定义前缀索引,因为mysql不允许索引它们的全文化. 可以在同一

1.创建表,存储引擎为myisam,对大文本字段blob使用MD5函数建立一个散列值 create table t2(id varchar(60), content blob, hash_value varchar(40))engine=myisam default charset=utf8; 2.插入数据 insert into t2 values(1, repeat('world1', 20), md5(content)); insert into t2 values(2, repeat('

-- 查看出现频率select count(*) as cnt,cityfrom sakila.city_demo group by city order by cnt desc limit 10; 1.select count(distinct city)/count(*) from sakila.city_demo; *完整列的选择性 2. select count(distinct left(city,3))/count(*) as sel3 ,count(distinct left(ci

有时候需要索引很长的字符列,这会让索引变得大且慢.通常可以索引开始的部分字符,这样可以大大节约索引空间,从而提高索引效率.但这样也会降低索引的选择性.索引的选择性是指不重复的索引值(也称为基数,cardinality)和数据表的记录总数的比值,范围从1/#T到1之间.索引的选择性越高则查询效率越高,因为选择性高的索引可以让MySQL在查找时过滤掉更多的行.唯一索引的选择性是1,这是最好的索引选择性,性能也是最好的. 一般情况下某个前缀的选择性也是足够高的,足以满足查询性能.对于BLOB,TEXT

MySQL有一个很有意思的索引类型,叫做前缀索引,它可以给某个文本字段的前面部分单独做索引,从而降低索引的大小. 其实,Oracle也有类似的实现,对于文本,它可以通过substr的函数索引,实现同样甚至更多的功能.另外,经过探索,我们发现,原来数字和时间字段,在Oracle也可以实现类似的功能. MySQL的前缀索引 MySQL的前缀索引指的是对指定的栏位的前面几位建立的索引. Altertable Table_Name add key(column_name(prefix_len)); 或者

高效使用索引的首要条件是知道什么样的查询会使用到索引,这个问题和B+Tree中的“最左前缀原理”有关,下面通过例子说明最左前缀原理. 一.最左前缀索引 这里先说一下联合索引的概念.MySQL中的索引可以以一定顺序引用多个列,这种索引叫做复合(联合)索引,一般的,一个联合索引是一个有序元组<a1, a2, …, an>,其中各个元素均为数据表的一列,实际上要严格定义索引需要用到关系代数,但是这里我不想讨论太多关系代数的话题,因为那样会显得很枯燥,所以这里就不再做严格定义.另外,单列索引可以看成联

没有索引时mysql是如何查询到数据的 索引对查询的速度有着至关重要的影响,理解索引也是进行数据库性能调优的起点.考虑如下情况,假设数据库中一个表有10^6条记录,DBMS的页面大小为4K,并存储100条记录.如果没有索引,查询将对整个表进行扫描,最坏的情况下,如果所有数据页都不在内存,需要读取10^4个页面,如果这10^4个页面在磁盘上随机分布,需要进行10^4次I/O,假设磁盘每次I/O时间为10ms(忽略数据传输时间),则总共需要100s(但实际上要好很多很多).如果对之建立B-Tree索

索引 索引是一种特殊的文件,它们包含着对数据表里所有记录的引用指针.更通俗的说,数据库索引好比是一本书前面的目录,能加快数据库的查询速度. 联合索引 又名复合索引,由两个或多个列的索引.它规定了mysql从左到右地使用索引字段,对字段的顺序有一定要求.一个查询可以只使用索引中的一部分,更准确地说是最左侧部分(最左优先).如索引是key index (a,b,c). 可以支持a | a,b| a,b,c 3种组合进行查找,但不支持 b,c进行查找 .当最左侧字段是常量引用时,索引就十分有效. CR

Mysql可以使用字符串前缀 作为索引 以节约空间. 下面我们以 Java的UUID 生成的 32位(移除UUID中的 中划线)字符串 来做一下 测试. 表结构: CREATE TABLE `test_uuid` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `uuid` varchar(36) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB AUTO_INCREMENT DEFAULT CHA

引入 通常在开发中我们需要定义字符串类型的字段,例如用户名或者用户邮箱等. 假设我们在维护一个用户登录系统,用户表的定义: create table User( ID bigint unsigned primary key, email varchar(64) )engine=Innodb; 如果使用邮箱登录的话,查询语句可能这样写: select ID from User where email='xxx'; 如果email字段没有加索引,那么这个语句只能做全表扫描. 前缀索引 MySQL是支

Mysql如何创建短索引 为什么要用短索引 有时需要索引很长的字符列,它会使索引变大并且变慢.一个策略就是模拟哈希索引.但是有时这也不够好,那么应该怎么办呢?通常可以索引开始的几个字符,而不是全部值,以节约空间并得到好的性能.这使索引需要的空间变小,但也会降低选择性.索引选择性(INDEX SELECTIVITY)是不重复的索引值(也叫基数(Cardinality))和表(#T)中所有行的比值,它的值在1/#T和1之间.高选择性的索引有好外,因为它使MYSQL在查找匹配的时候可以过滤掉更多的行,

计算适合设置索引的长度,直到去重以后在一个固定值. 根据去重以后适合的长度设置索引. 计划查询

现有一数据表,数据量79W, 微信openid字段为定长28位char型,目前是做的全字段索引,需要做一下索引优化,. 我们先来看下选择性, 全字段索引的: SELECT COUNT(DISTINCT(`openid`)))/COUNT(*) AS selectability FROM `mytable` selectabiliy ------------ 0.8750 取前8位: )))/COUNT(*) AS selectability FROM `mytable` selectabiliy

在mysql中有时需要索引的列很长,如果直接应用索引会造成索引过大的问题.因此我们可以取其中一部分字段来做索引,例: 添加索引:alter table * add key (field(3));    //field索引字段, 3索引字符数 但是我们怎样确定取多长的字符数的为最合理的索引长度: 通过:select count(field)/count(*) from table;语句获取选择率, 然后:select count(distinct left(field, n))/count(*)

创建一个测试用表 mysql> desc two; +-------+-------------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +-------+-------------+------+-----+---------+----------------+ | id | ) | NO | PRI | NULL | auto_increment | |

数据库的索引可以加快查询速度,原因是索引使用特定的数据结构(B-Tree)对特定的列额外组织存放,加快存储引擎(索引是存储引擎实现)查找记录的速度.索引优化是数据库优化的最重要手段. 如果查询语句使用索引(通常是where条件匹配索引)就会利用树的结构加快查找,索引会按值查找到要查找的行在表中位置,不需回表查询数据的就是聚簇索引(索引和数据存放在一起).通常是需要回表再查数据,需要消耗额外的磁盘IO.所以有些时候(如按顺序读取数据)全表扫描会比使用索引快的原因就在于此. 查询条件只有一个字段时,

索引优化策略 :索引类型 .1B-tree索引 关注的是:Btree索引的左前缀匹配规则,索引在排序和分组上发挥的作用. 注:名叫btree索引,大的方面看都用的二叉树.平衡树.但具体的实现上,各引擎稍有不同.比如,严格的说,NDB引擎,使用的是T-tree.Myisam,innodb中,默认用B-tree索引. 凡是tree系列的,可理解为”排好序的.快速查找.的结构”.是排好序的,所以查询某个范围就很快. btree索引的常见误区:在where条件常用的列上都加上索引, 例: ; //查询第