适用分区或者说分表最多的场景依然是针对时间字段做拆分， 这节我们详细讲讲如何更好的基于时间字段来拆分。分别按照年、月、日几个维度的实现方法以及一些细节注意事项。第一，以年为维度做拆分日期字段拆分粒度的选择跟业务检索请求密切相关。比如保留10年数据，每次查询基于某个具体年份做为过滤条件，那按照年拆分肯定最好。例如下面SQL：select * from ytt_pt1 where log_date &
一般提到索引，大家都只关注索引的优点，一个优秀的索引的确会让查询请求的效率大幅提升、亦或是
些我前面三篇文章已经详细讲过。但是这种分割方法对多字节字符.
预期，总体查询时间较慢，这时可能得.
集索引。与非聚集索引相比，聚.
关系表设计合理与否是影响关系型数据库性能的核心要素之一。谈到关系型数据库表设计问题，首先想到的是范式理论。也就是说一张表的设计首先要满足一定的范式，完了后再根据一定的需求来反范式设计，也即冗余备用设计。数据库范式一般包含6个，分别为1NF、2NF、3NF、BCNF、4NF、5NF。 这6个范式级别分别从数据是否允许一定范围的冗余、数据是否更加精细化的管理这两个关键点出发，越往后，数据越规范，冗余越
er table t1 add key idx_multi_1(r1,r2,r3) ;唯一索引，建议以 udx_ 为开头，字母全部小写；如果是多.
接着讲 MySQL 全文索引，这篇主要探讨 MySQL 全文索引的监测。MySQL 有很完整的元数据表来监测全文索引表的插入，更新，删除；甚至全文索引表以及辅助表的数据追踪。这里分为三个部分：第一部分，介绍监测相关参数；第二部分，介绍监测相关元数据表；第三部分，实例演示如何进行监测。第一部分， 全文索引监测相关参数：innodb_ft_aux_table： 动态设置被监测的全文索引表名。 这个参数
上一篇介绍了全文索引的基本原理，这篇来讲讲如何更好的使用全文索引。全文索引的检索和普通检索的语法不同，普通检索一般类似下面SQL：select * from tb1 where id in (1,2);select * from tb1 where id < 10;过滤条件在WHERE子句后面，以一定的方式来拼接SQL，全文索引的使用有特定的语法：MATCH (col1,col2,...)
表的主键指的针对一张表中的一列或者多列，其结果必须能标识表中每行记录的
引言上一章节我们探讨过数据垂直拆分，今天我们来继续讨论数据拆分：水平拆分！水平拆分和垂直拆分有些不一样，垂直拆分最小单元是字段，与业务有很强的关联性，具体业务对应具体的拆分数据；而水平拆分最小单元是数据行，与具体业务关系不大，业务关联可以是拆分后的单张表数据，也可以是拆分前的全局数据。简单来说，水平拆分对应用透明，应用逻辑在数据拆分后不需要大动。正文一般在关系数据库中，水平拆分具体对应两个方面：第
前面介绍了 B 树索引、哈希索引，接下来看看 MySQL 全文索引。在讲全文索引之前，可以看看如下很常见的一类 SQL 语句：select count(*) from fx where s1 like '%cluster%'这条语句从表 fx 中检索字段 s1，过滤条件为 ‘%cluster%’，这样的模糊查找语句性能很差，即使在字段 s1 上有索引也因无法找到切入点从而对表 fx 进行全表扫描，
引言一般来说讲，提到数据拆分，可以归结为两个层面：一是垂直拆分，二是水平拆分。这里我们来讨论下垂直
上篇文章已经详细介绍 MySQL 组合索引的概念以及其适用场景，这篇主要介绍 M
说到这儿，可能有的人会有些疑问： 多值索引不就是联合索引吗，还需要单独开
基于时间类分区我之前写过实现篇、细节篇。今天来继续分享一下时间类分区的真实案例：某家互联网公司数据库系统的表调优过程。问题与背景：单张表数据量太大，每天会产生 10W 条记录，一年就是 3650W 条记录，对这张表的查询 95% 都是在某一天或者几天内，过滤区间最大不超过一个月。比如在2019年3月1日、2019年4 月20 日或者是2019年5月1日和2019年5月5日这个时间段内。偶尔会涉及到
这里主要介绍 MySQL 的前缀索引。从名字上来看，前缀索引就是指索引的前缀
上篇《MySQL 时间类分区具体实现》介绍了时间类分区的实现方法，本篇是对上篇的一个延伸，介绍基于此类分区的相关 SQL 编写注意事项。对于分区表的检索无非有两种，一种是带分区键，另一种则不带分区键。一般来讲检索条件带分区键则执行速度快，不带分区键则执行速度变慢。这种结论适应于大多数场景，但不能以偏概全，要针对不同的分区表定义来写最合适的 SQL 语句。用分区表的目的是为了减少 SQL 语句检索时
本篇主要介绍 MySQL 的函数索引（也叫表达式索引）。通常来讲，索引都是基于
建立在多个列上的索引即组合索引（联合索引），适用在多个列必须一起使用或
MySQL InnoDB 表数据页或者二级索引页（简称数据页或者索引页）的合并与分裂对
引言：上一篇我介绍了 MySQL 范式标准化表设计，范式设计具有以下优点：把如何消除数据冗余做到极
谈到索引，大家并不陌生。索引本身是一种数据结构，存在的目的主要是为
M用层部署路由或者中间层。接下来我们用实际例子来让前两种优势体现更新清晰。.
相信大家通过前几篇文章，已经了解了 MySQL 字符集使用相关注意事
表空间的选择，可以说是对表的日常管理以及访问性能有非常紧密的联系。表空间
索引下推（INDEX CONDITION PUSHDOWN，简称 ICP）是 MySQL 5.6 发布后针对扫描二级索引的一项优化改进。总的来说是通过把索引过滤条件下推到存储引擎，来减少 MySQL 存储引擎访问基表的次数以及 MySQL 服务层访问存储引擎的次数。ICP 适用于 MYISAM 和 INNODB，本篇的内容只基于 INNODB。MySQL ICP 里涉及到的知识点如下：1.MySQ
一、概念压缩表从名字上来看，简单理解为压缩后的表，也就是把原始表根据一定
这里讲述 MySQL 哈希索引的实现方式以及使用场景。哈希表在 MySQL 里有如下应用：各种存储引擎的哈希索引存储。MySQL 的 Memor
这篇主要说明表属性 - 外键。外键的设计初衷是为了在数据库端保证对逻辑上相关联的
Copyright © 2005-2023 51CTO.COM 版权所有 京ICP证060544号
