MySQL

  • MySQL的不可见索引

    ·

    不可见索引(Invisible Indexes)MySQL 8.0之后引入的一个重要特性。也可以帮助DBA或者开发者更好的管理和维护数据库的索引。本文将介绍不可见索引的一些常见使用场景和注意事项。

    更加安全的删除没用的索引

    通常,线上运行时间较长的系统,可以通过索引使用统计信息知道哪些索引是从来不被使用的,但依旧会占用磁盘空间,并且会影响系统的写入/更新/删除操作的性能。但是删除索引的操作,有时候也会带来意想不到的系统性能下降,所以,在正式删除之前,可以先将索引修改为不可用,待观察数日后再进行删除,会更加安全。

    性能分析

    有时候在对线上系统进行SQL性能分析时,有时候为了排除某些索引对查询性能影响时,可以暂时的将某些索引暂时标记为不可用,再统计此时的SQL执行时长与性能。然后,再将索引置为可见,再次执行SQL,并统计执行时长与性能。

    通过这样对比,可以非常简单直观、量化的观察到索引对对于具体SQL性能的提升。

    不可见索引依旧会有维护成本

    虽然不可见索引不会被查询优化器使用,但在对数据进行DML操作(如:插入、更新、删除)时仍会被维护。这意味着不可见索引可能会对数据库性能产生一定影响。在使用不可见索引进行性能测试或分析时,请务必权衡这一点。

    不建议长期保留不可见索引

    如果确定某个不可见索引对查询性能没有帮助,建议尽早删除该索引,以节省存储空间和减小维护成本。否则,该索引对系统性能没有起到任何正面作用,反而会占用空间,并影响DML的性能。

    优化器选项可以让不可见索引生效

    在优化器选项(optimizer_switch)中,可以通过打开标记位(use_invisible_indexes),来强制优化器忽略索引的不可见属性,这在增加了SQL性能调试时的灵活性。

    可以通过SELECT/SHOW命令查询优化器选项,也可用通过SET命令变更该选项:

    SET [GLOBAL|SESSION] optimizer_switch='command[,command]...';
    
    SET SESSION optimizer_switch = 'use_invisible_indexes=ON';
  • 在日常编写SQL中,使用变量来灵活的构建执行的SQL语句是比较常见的。就像在编程中使用变量、函数参数等是一样的道理。本文介绍使用JSON函数(JSON_ARRAYJSON_SEARCH)、以及 FIND_IN_SET 如何简单的实现带有数据组变量的SQL拼接与执行。使用该方法,则无需使用CONCAT函数拼接SQL,再使用PREPARE/EXECUTE语法执行,所以会更加简洁,可读性、扩展性更强。

    具体的,例如需要再查询结果中找到u_name在数组@u_list_j中的记录,那么使用JSON方式可以按照如下模式实现:

    SET @u_list_j = JSON_ARRAY('zhou','wu','zheng','wang','zhuge');
    
    SELECT 
        id,u_name 
    FROM 
        t_01 
    WHERE 
        JSON_SEARCH(@u_list_j,'one',t_01.u_name);

    另一种较为常见的方法是使用 FIND_IN_SET 函数。其使用方法如下:

    set @u_list_s = 'zhou,wu,zheng,wang,zhuge';
    
    SELECT 
        u_name 
    FROM 
        t_01 
    WHERE 
        FIND_IN_SET(t_01.u_name,@u_list_s);

    另外,还可以尝试使用 LOCATE 函数实现,只是使用该函数需要注意,在做字符串匹配的时候容易出现的重复、错误匹配问题。例如,数组中存在”zhuge”,那么匹配”zhu”,则可能匹配成功,但这并不是期望的结果。

    示例表:

    本文中使用的一些示例表如下:

    CREATE TABLE t_01(
      id int UNSIGNED AUTO_INCREMENT primary key,
      u_name varchar(32)
    );
    
    INSERT INTO t_01(u_name) values
      ('wu'),
      ('zhao'),
      ('qian'),
      ('sun'),
      ('li');
  • 如何学习MySQL

    ·

    《高性能MySQL》第四版发布后,收到了很多读者的反馈,其中关注最多的是作为一个初学者,应该如何能够较为系统的学习MySQL,从而应对日常工作或者获得更好的职业发展。于是和多个业内朋友讨论后,整理了一些MySQL学习的推荐资源,供初学者参考。文章末尾有一个MySQL学习交流群,供加入提问与讨论。


    业界专家的经验

    Yangyidba 阿里云的数据库专家

    yangyidba 阿里云数据库专家

    刚刚入行时,有哪些资料给你了帮助?

    正式接触 MySQL 是2011年底,当时的公司的数据库版本主要是 5.5 版本和少量 5.1 版本。因为之前学Oracle的经验是查看官方文档,学习MySQL 资料主要是 “官方文档” 和当时的淘宝DBA团队组织的技术大学的技术分享,学习MySQL技术的技术特性和经典案例。

    其实就现在而言,MySQL 官方文档依然是最好的学习资料和教材, 里面非常详细的说明 MySQL的基础架构,redo,undo,读写逻辑,字段类型,锁,存储引擎,主从复制,MGR ,性能优化等等。把官方文档通读一遍,基本上能超越60-70%左右的DBA,为什么不是更高呢?因为学习技术是为了使用技能。

    进一步了解 MySQL/数据库,是哪些资料帮助了你?

    (more…)
  • 数据库图形客户端(GUI)工具,可以大大帮助开发者提升SQL编写与开发的效率。在云时代,企业越来越多的开始采用RDS,同时也还有部分本地IDC自建数据库,而在云端也会选择/尝试多个不同云厂商。“工欲善其事,必先利其器”,在这样的背景下,看看有哪些工具产品可供选择吧。

    整体综述

    本文完整对比了12种MySQL图形客户端(GUI)工具,从产品体验、功能完整度、云适配、计费模式、OS兼容性等多个角度进行评估与分析,给出推荐。下面产品推荐与整体得分图,读者可根据自己的实际情况选择:

    (more…)
  • Oracle对MySQL5.7的扩展支持到2023年10月就结束了,之后可能不再发布新的版本,是时候更多的了解MySQL 8.0了。同时,再看看各个云厂商对于用户和角色的支持情况。

    从8.0开始,MySQL开始支持“角色”,帮助用户更好的进行权限管理,使用角色功能,可以批量、规模化的管理用户的权限。如果,需要较大规模新建用户,并对其权限进行管理的时候,这个功能将大大简化权限增加、减少时候的管理工作。

    另外,在8.0版本中,MySQL对角色的设计上,非常的“偷懒”,因此,还有很多的隐藏的打开方式,附带的也留下了一些坑需要注意。

    基础使用示例

    基础的:

    • “角色”是代表”一组权限”(例如,某个数据库的读权限、写权限等)的对象,可以将角色赋予某个用户后,该用户使用该角色运行时,则具备这”一组权限”。
    • 当角色的权限发生变化(例如,收回或者新增权限)时,对应用户(使用该角色时)的权限也会跟着改变,这对于规模化的用户、权限管理是很方便的。

    我们看看如下场景与示例:

    (more…)
  • 一直以来实现数据库的零数据丢失都是非常有挑战,尤其是跨可用区的场景下。很多核心系统为了实现这一点都投入了大量的智慧和金钱。Amazon RDS在文档都明确的写到,数据库在多AZ之间的数据是保持同步的(注:同步是指数据写入两边要同时写成功,即使一边不可用,已经提交的事务在另一边一定是成功的)。一直以来,我也很好奇Amazon RDS在哪个层面实现的同步复制。

    这个问题原本也是没有太大疑问的,可以推测应该是通过EBS层面的块复制来下。依据有两方面,有一些公开的Amazon RDS一些架构图中可以看到有EBS复制的箭头说明。另外,还有一点,只有通过EBS的复制实现跨可用区数据一致性,才可能在RDS支持的多种数据库,如MySQL、SQL Server、Oracle等,上保持架构上一致。否则,不同数据库类型的高可用和复制架构可能相差很大。

    但是,之前很长时间我还是有一个疑问,Amazon RDS复制到底是在数据库逻辑层实现的还是在EBS物理层实现的。

    既然有上面的猜测,那为什么产生了这个疑问呢?是因为,在Aurora很多的对外介绍材料(包括论文、架构介绍的slide)中,会放一个MySQL架构来突出Aurora的架构优势。这个图一直让我误以为Amazon RDS使用了数据库的binlog的复制。在了解Aurora的时候大家经常会看到如下架构图作为反面案例(参考): (more…)