• ⛽️🦆
    2019-11-29
    您好,老师:
    回答上述问题
    1.创建多的索引,会占用更多磁盘空间。如果有一张很大的表,索引文件的大小可能达到操作系统允许的最大文件限制;
    2.对于DML操作的时候,索引会降低他们的速度。因为MySQL不仅要把搞定的数据写入数据文件,而且它还要把这些改动写入索引文件;
    改善数据库性能:
    1.索引优化,选择合适的索引列,选择在where、group by、order by、on 从句中出现的列作为索引项,对于离散度不大的列没有必要创建索引。
    2.索引字段越小越好。
    3.SQL语句的优化、数据表结构的优化。
        3.1:选择可存数据最小的数据类型,选择最合适的字段类型,进行数据的存储;
        3.2:数据量很大的一张表,应该考虑水平分表或垂直分表;
        3.3:尽量不要使用text字段,如果非要用,那么应考虑将它存放另一张表中;
    4.数据库配置的优化:
        4.1:连接数的配置,因为大量的连接,不进行操作,那样也会占用内存。
        4.2:查询缓存的配置,但在MySQL 8.0就删除了此功能。
    5.硬件的配置;
     额外加说一下,常见性能的问题:
    1.条件字段函数的操作,给索引字段做了函数计算,就会破坏索引值,因此优化器就放弃了走树搜索能够;
    2.隐式类型转换,比如数据库字段是varchar类型,创建的索引,但是使用的时候传入的是int类型,那么会走全表扫面;
    3.隐式字符编码转换,如果join 两表的时候,两表的字符集不同,也不能用上索引;
    展开
     3
     36
  • 尹宗昌
    2019-11-29
    索引可以提高查询性能,但是一定要考虑维护索引的成本。空间占用、插入修改的性能影响都要衡量
    
     2
  • 无形
    2019-12-01
    最近在广告检索中接入了用户画像标签,实现了把一大串嵌套json格式的标签数据表达式,类似dnf表达式,解析为可计算的广告匹配模型,其中就有类似sql一样,对表达式进行格式分析、数据、比较符检验、复杂的逻辑关系转换为容易处理的计算单元,最后生成一个树状匹配模型,通过对模型输入用户数据,进行匹配,并返回符合的用户。
    这有点像用户画像标签就是一条SQL,对SQL进行语法分析,生成匹配模型(类比SQL的执行计划),当下次输入用户数据的时候用生成好的匹配模型直接处理数据,不必再重复解析画像标签
    
     1
  • Zend
    2019-12-01
    请问一下老师PreparedStatement经过语法分析生成的抽象语法树,再经过语义分析和优化器处理后生成的执行计划,会有缓存吗?

    作者回复: 会

    
     1
  • Zend
    2019-12-01
    请问老师,在进行事务操作时,事务日志文件会记录更新前的数据记录,这个记录更新前的数据记录是 什么意思,是把更新之前的数据都查询出来,记录到事务日志文件嘛

    作者回复: 是的,更新数据本来就会先执行查询操作。

    
     1
  • 乘坐Tornado的线程魔...
    2019-11-30
    请问下,文中的第一个B+树示意图的第一层中间节点,8和34中间的部分是不是也应该指向一个子节点?

    作者回复: 是的,图中只是示意,没有画出全部节点。

    
     1
  • 灰灰
    2019-12-17
    打卡
    
    
  • Paul Shan
    2019-12-05
    聚簇索引,叶子节点指向了记录。
    非聚簇索引,叶子节点指向了主键。
    索引肯定不是越多越好,不然就会默认创建。索引有成本,成本来自于存储成本和插入删除时候的维护成本,如果查询得到的好处不足以抵消维护和存储成本,就是不值得的。
    
    
  • 无形
    2019-12-01
    数据变动的时候同时需要更新索引,索引多了,数据变动的效率就会降低,索引也是文件,会占用更多的磁盘空间
    。
    另外,我之前提到的要动手实现的高性能检索系统,在数据的存储部分,用文件存储,为了提高文档的检索效率,为文件创建了索引,索引是这种格式id:start:length,
    文档id:在文件中的起始位置:文档的长度,索引文件是排序过得,例如下面这种格式
    0000000001:0000000000:0000000100
    0000000002:0000000100:0000000300
    0000000007:0000000400:0000001000
    在不加载完整索引文件的情况下,这样可以通过offset快速读取每个索引数据,因为是排序过的,二分查找快速查找到文档的起始位置和大小,就可以迅速在文件中找到文档,测试了下,文档数据量160w,最多20次就可以查找到文档,耗时200-300微妙,如果对索引文件进行分片存储还会更快
    展开
    
    
  • 一步
    2019-11-30
    SQL 的分析器 包括词法分析器和语法分析器,经过词法分析器生成 AST ,不是语法分析
    
    
  • 乘坐Tornado的线程魔...
    2019-11-30
    印象中丁奇的《MySQL实战45讲》中,也讲到了回表。但是文中提到的MySQL是聚簇索引,不需要回表。是不是这里面有些概念需要根据具体情况再进一步拆分讨论。并不能一概而论?
     7
    
  • 老王的老李头
    2019-11-30
    李老师,堪比百科全书啊!非常接地气!给老师提个建议,文章中有些是针对MySQL说的,有些不是,希望老师能区分一下。
    索引么,也是一种空间换时间的思路,细思极恐。改善数据库访问性能的手段也不应该仅限于索引这种手段。
    
    
  • 俊伟
    2019-11-29
    1.索引较多,插入删除的时候会有额外的开销。
    2.索引字段尽量小,因为索引字段的大小会影响每一个b+树节点数据块中的数据项的个数。
    3.多了解业务,有些地方可以使用索引有些则不用。
    4.可以综合利用联合索引和单独索引
    
    
  • 幸福来敲门
    2019-11-29
    哎
    
    
我们在线,来聊聊吧