高性能mysql 第5章 创建高可用的索引

一定程度上说,mysql只有b-tree索引。他没有bitmap索引。还有一个叫hash索引的,只在Memory存储引擎中才有。

b-tree索引跟oracle中的大同小异。

mysql中关于b-tree的限制:

只有做全值拼配或者根据左前缀匹配。我猜测是因为mysql没有基于cost的优化器,它没有对index full scan的操作。因为无法衡量这种full scan是否划得来。所以只能对前缀进行匹配,没有后缀或者中间匹配这种逻辑。

如果是多列索引,顺序很重要,如果没有从索引的第一列开始查询,那么将不会使用索引。

比如索引建立在A,B,C列上。

  • 如果对B= ? and C = ? 无法使用索引
  • 如果对 A = ? and C = ? 只能A =?生效 使用索引。

始终将索引的列放在查询的一边,如A + 1 = 2,这种情况不会使用索引,应该是写A = 1。(可能是因为mysql处理的时候,A + 1 是作为隐藏的函数来处理的)。A如果作为函数的参数,也无法使用索引。

前缀索引:

前缀索引用在大字段上或者长度比较尝的字符串上,使用字符串的前缀作为索引。传入一个参数,代表截取的长度。

语法:

  1. create
    index idx_t_test_c_char1 on t_test(c_char(3)); create
    index idx_t_test_c_char1 on t_test(c_char(3));
  2. explain select * from t_test t where t.c_char = ‘12455‘

结果:

使用了索引。

前缀索引的缺陷:因为只存储了前缀,所以无法作为数据来操作,如order by和group by的部分,无法使用这个索引来优化。

时间: 2024-11-08 11:50:18

高性能mysql 第5章 创建高可用的索引的相关文章

Cluster基础(四):创建RHCS集群环境、创建高可用Apache服务

一.创建RHCS集群环境 目标: 准备四台KVM虚拟机,其三台作为集群节点,一台安装luci并配置iSCSI存储服务,实现如下功能: 使用RHCS创建一个名为tarena的集群 集群中所有节点均需要挂载iSCSI共享存储 使用集群中任意节点对iSCSI设置进行分区格式化 安装luci的虚拟主机要求额外添加一块20G硬盘 物理主机IP地址为192.168.4.1,主机名称为desktop1.example.com 方案: 使用4台虚拟机,1台作为luci和iSCSI服务器.3台作为节点服务器,拓扑

kubeadm创建高可用kubernetes v1.12.0集群

节点规划 主机名 IP Role k8s-master01 10.3.1.20 etcd.Master.Node.keepalived k8s-master02 10.3.1.21 etcd.Master.Node.keepalived k8s-master03 10.3.1.25 etcd.Master.Node.keepalived VIP 10.3.1.29 None 版本信息: OS::Ubuntu 16.04 Docker:17.03.2-ce k8s:v1.12 来自官网的高可用架构

[转帖]【MySQL+keepalived】用keepalived实现MySQL主主模式的高可用

[MySQL+keepalived]用keepalived实现MySQL主主模式的高可用 https://www.jianshu.com/p/8694d07595bc 一.实验说明 MySQL主主模式,是两台MySQL数据库互为主从. 此实验是用keepalived实现MySQL主主模式的高可用,基于已经安装好了主主架构的MySQL,然后配置keepalived,验证高可用性! 二.实验环境 操作系统:CentOS 7.5 serverA:192.168.1.104 serverB: 192.1

通过KeepAlived搭建MySQL双主模式的高可用集群系统

企业级MySQL集群具备高可用.可扩展.易管理.低成本的特点.下面将介绍企业环境中经常应用的一个解决方案,即MySQL的双主互备架构,主要设计思路是通过MySQL Replication技术将两台MySQL Server互相将对方作为自己的Master,自己又同时作为对方的Slave来进行复制.这样就实现了高可用构架中的数据同步功能,同时,将采用KeepAlived来实现Mysql的自动failover.在这个构架中,虽然两台MySQL Server互为主从,但同一时刻只有一个MySQL Ser

MySQL双主+keepalived实现高可用

mysql+keepalived实现高可用+主主复制模式 为了解决mysql的单点故障问题,衍生出很多mysql的高可用方案: keepalived+双主.MHA.PXC.MMM.Hearbeat+DRBD等,比较常用的一般是keepalived+双主,MHA和PXC 在此搭建实验环境,实现keepalived+mysql双主模式. 实验思路: 两台MySQL互为主从关系(双主),通过keepalived配置虚拟vip,实现当其中的一台MySQL数据库宕机后,应用能自动切换到另外一台MySQL数

heartbeat+mysql双主复制实现高可用

实验环境 一:搭建主主复制环境 1.1实验环境 两台机器事先都已经装好了MySQL单实例. IP: 10.192.203.201 10.192.203.202 端口都是3307. 二者的端口号需要保持一致,否则在最后用vip连接的时候,不能使用相同端口号连接. 1.2实验步骤 1.2.1修改配置文件 修改master1: 在[mysqld]下面添加: server-id = 1 relay-log=/data/server/mysql_3307/binlog/ZabbixServer-relay

MySQL主主+Keepalived实现高可用

在企业中,数据库高可用一直是企业的重中之重,中小企业很多都是使用mysql主主方案,一主多从,读写分离等,但是单主存在单点故障,从库切换成主库需要作改动.因此,如果是双主或者多主,就会增加mysql入口,增加高可用.不过多主需要考虑自增长ID问题,这个需要特别设置配置文件,比如双主,可以使用奇偶,总之,主之间设置自增长ID相互不冲突就能完美解决自增长ID冲突问题 主主方案实现思路 1. 两台mysql都可读写,互为主备.默认只使用一台masterA负责数据的写入,另一台masterB备用处于备用

高性能mysql 第10章 复制

复制功能不仅能够构建高可用的应用,同时也是高可用性,可扩展性,灾难恢复,备份以及数据仓库等工作的基础. mysql支持两种复制方式:基于语句的复制和基于行的复制.基于语句的复制(也成为逻辑复制)是早期版本提供的功能,基于行的复制是5.1版本加入的.这两种方式都是通过在主库上记录二进制日志,在从库上重放日志来实现异步的数据复制.这意味着,同一时间,主库和从库的数据可能是不一致的.并且无法保证主从之间的延迟.一些大的语句可能导致主从之间几秒,几分钟,甚至几小时的延迟. 复制通常不会增加主库的开销.主

企业级-Mysql双主互备高可用负载均衡架构(基于GTID主从复制模式)

前言: 原理与思想 这里选用GTID主从复制模式Mysql主从复制模式,是为了更加确保主从复制的正确性.健康性与易配性.这里做的是两服务器A,B各有Mysql实例3310,两个实例间互为主从 主从复制模式采用GTID主从复制模式,在服务器A,B上配置keepalived负载均衡,通过VIP连接数据库,目的是一旦有某数据库宕机,keepalived 就会立即建VIP执行另外一台 健康的数据库实例上,实现快速切换,避免单点故障,从而保证业务的正常运行. 这里只做了 双主+keepalived  ,