企业官网建设流程全解析

普陀网站制作,wordpress的图片代码是什么,网站 备案 名称,国外网站模版先搞懂几个基础前提一步步算B树高度能存多少数据第一步#xff1a;算非叶子节点能存多少个索引项第二步#xff1a;算叶子节点能存多少行数据第三步#xff1a;算不同高度的B树能存多少数据怎么验证自己表的索引高度#xff1f;单表多少数据不影响性能#xff1f;数据超阈…先搞懂几个基础前提一步步算B树高度能存多少数据第一步算非叶子节点能存多少个索引项第二步算叶子节点能存多少行数据第三步算不同高度的B树能存多少数据怎么验证自己表的索引高度单表多少数据不影响性能数据超阈值了怎么优化最后聊几句补充为啥IO次数树高度B树查数据完整流程拆解先搞懂核心IO次数树高度的原因查数据的完整流程以高度3的B树为例1. 第一次IO读取根节点内存中速度快2. 第二次IO读取中间节点大概率也在内存3. 第三次IO读取叶子节点可能需要磁盘IO4. 特殊情况范围查询/全表扫描再总结下核心逻辑平时写SQL查询总听说“索引能提速”但很少想过索引背后的B树到底是怎么工作的。直到最近被问到“单表千万数据查询为啥还快”才去研究了B树索引高度的计算发现里面藏着挺多实用的逻辑今天用大白话跟大家聊聊。先搞懂几个基础前提聊计算之前得先明确几个InnoDB的默认配置这些是计算的基础记不住也没关系知道有这么回事就行页大小默认16KB也就是16384字节B树的每个节点都对应一个这样的页指针大小固定6字节用来指向子节点的地址主键类型影响索引项大小比如INT是4字节BIGINT是8字节VARCHAR(32)就得322字节B树结构非叶子节点只存“主键指针”叶子节点存“主键完整行数据”而且叶子节点是双向链表连起来的我认为这些基础参数不用死记硬背但知道它们的存在后面看计算过程就不会懵了。一步步算B树高度能存多少数据计算核心就是先算每个节点能存多少东西再算整棵树能装多少行数据咱们分三步来用实际例子更直观。第一步算非叶子节点能存多少个索引项非叶子节点只存“主键指针”所以先算一个索引项占多少字节再看16KB的页能装多少个。举个常见的例子主键是INT4字节 指针6字节 一个索引项10字节。InnoDB的页不能全用得留部分给页头页尾我们的经验是按90%可用空间算也就是16384×90%≈14745字节。那单页能存的索引项数就是14745÷10≈1474个——这意味着每个非叶子节点能指向1474个子节点。第二步算叶子节点能存多少行数据叶子节点存的是“主键完整行数据”所以得算一行数据总共占多少字节。还是用上面的主键INT4字节假设其他列加起来大概100字节那一行就是104字节。同样按14745字节的可用空间算单页能存的行数就是14745÷104≈141行。第三步算不同高度的B树能存多少数据B树是多叉树总数据量的公式很简单总行数 非叶子节点分支数^(高度-1) × 叶子节点单页行数。咱们代入上面的数值算一算高度1只有根节点也是叶子节点能存≈141行数据高度2根节点非叶子 叶子节点1474×141≈20.8万行高度3根→中间节点→叶子1474×1474×141≈3060万行高度41474³×141≈45亿行看到这是不是很惊讶我第一次算的时候也没想到高度3的B树居然能存3000多万行数据而查询的时候只需要3次磁盘IO——这就是为啥千万级数据查询还能很快的原因。怎么验证自己表的索引高度光说不算咱们可以直接查MySQL的系统表看看实际表的索引高度是多少。步骤很简单先查目标表的TABLE_ID再查索引高度-- 第一步查TABLE_ID把数据库名和表名换成自己的SELECTTABLE_IDFROMinformation_schema.INNODB_SYS_TABLESWHERENAME数据库名/表名;-- 第二步查主键索引高度SELECTb.nameAS表名,a.HEIGHTAS索引高度FROMinformation_schema.INNODB_SYS_INDEXES aJOINinformation_schema.INNODB_SYS_TABLES bONa.TABLE_IDb.TABLE_IDWHEREb.TABLE_ID上面查到的TABLE_IDANDa.NAMEPRIMARY;-- 只查主键索引我查过公司几个业务表大部分都是高度3只有一个几百行的小表是高度2。按这情况只要单表数据没超过3000万索引高度基本都是3查询性能不会有啥问题。单表多少数据不影响性能很多人会问“单表最多能存多少行不卡”其实没有绝对答案但业界有通用经验。我认为核心不是行数而是索引高度和IO能力索引高度≤3时查询只要2~3次IO而且根节点和中间节点通常会常驻内存实际IO更少性能基本没衰减到了高度4就得4次IO中间节点可能存不下内存性能会明显下降给大家整理了不同场景的参考阈值日常开发可以参考场景不影响性能的最大行数核心限制因素主键查询热数据1亿行缓冲池大小建议≥32GB普通索引分页1000万行回表IO、分页排序开销频繁更新多索引500万行索引维护、锁竞争机械硬盘HDD500万行随机IO慢约100 IOPS固态硬盘SSD1亿行随机IO快约10万 IOPS数据超阈值了怎么优化如果数据量确实超过了上面的阈值单表优化效果就有限了这时候得从架构入手分库分表水平分表最常用按主键范围或哈希分让每个分表的行数回到千万级以内冷热数据分离把很久不用的冷数据归档到只读库主库只留热数据减轻压力索引优化少建冗余索引能用覆盖索引就不用SELECT *避免回表IO硬件升级把机械硬盘换成SSD增大InnoDB缓冲池一般设为物理内存的50%~70%最后聊几句B树索引高度的计算看着复杂其实核心就是“算每个节点能存多少再算整棵树的容量”。理解了这个逻辑就知道为啥千万级数据查询还能很快——因为索引高度没上去IO次数少。我们的经验是日常开发不用过度纠结索引高度只要做好这几点就行主键尽量用INT或BIGINT别用太长的VARCHAR减少索引项大小控制单行数据大小别搞太多大字段让叶子节点能存更多行数据量超千万后提前规划分库分表别等性能下降了再补救补充为啥IO次数树高度B树查数据完整流程拆解很多人可能会疑惑“为啥IO次数就等于树的高度”还有查数据的时候到底是怎么一步步找到目标的。我用更通俗的方式拆解下结合实际流程大家一看就懂。先搞懂核心IO次数树高度的原因首先得明确一个前提B树的每个节点都对应InnoDB的一个“页”而每个页默认是16KB一个页的读取就是一次磁盘IO——这是关键。我认为逻辑很简单B树是层级结构从根节点到叶子节点每往下走一层就需要读取一个新的节点页而每个节点的读取都要一次磁盘IO。最终找到数据刚好要经过“树的高度”个节点所以IO次数就等于树的高度。举个例子高度2的树根节点非叶子→ 叶子节点要读2个页就是2次IO高度3的树根节点→中间节点→叶子节点读3个页就是3次IO而且根节点和上层的中间节点因为被频繁访问InnoDB会把它们常驻在内存里实际查询时这几层的IO是内存IO速度极快只有最后访问叶子节点可能需要一次磁盘IO——但从理论上来说IO次数还是等于树的高度只是实际开销被内存缓存降低了。查数据的完整流程以高度3的B树为例假设我们有一张用户表主键是INT类型B树高度3要查询“主键10086的用户数据”整个过程就像“走导航找地址”一步步定位1. 第一次IO读取根节点内存中速度快根节点是B树的最顶层属于非叶子节点只存“主键子节点页指针”而且已经按主键排好序了。我们要找主键10086会先在根节点里做二分查找因为有序查找很快找到包含10086的主键范围对应的“子节点页指针”——比如根节点里有个索引项是100000x123456表示主键≥10000的 data 都存在地址为0x123456的中间节点里。这一步读取根节点算1次IO但因为根节点常驻内存实际是内存操作几乎不耗时。2. 第二次IO读取中间节点大概率也在内存中间节点同样是非叶子节点结构和根节点一样还是“主键子节点指针”也按主键排序。拿着刚才得到的页指针0x123456读取对应的中间节点页。继续在这个中间节点里做二分查找找到10086对应的叶子节点页指针——比如找到索引项100800x789abc表示主键≥10080且10090的 data 存在地址0x789abc的叶子节点里。这一步读取中间节点算第2次IO高度3的树里中间节点通常也会被缓存到内存开销很小。3. 第三次IO读取叶子节点可能需要磁盘IO叶子节点是最终存数据的地方结构是“完整主键整行数据”而且所有叶子节点通过双向链表连接。拿着中间节点给的页指针0x789abc读取对应的叶子节点页。因为叶子节点的主键也是有序的继续二分查找直接定位到“主键10086”的那一行数据。这一步是第3次IO如果这个叶子节点不在内存里就需要从磁盘读取这是整个流程中最可能耗时的一次IO但因为是16KB的连续数据速度也不慢。4. 特殊情况范围查询/全表扫描如果不是查单个主键而是范围查询比如“主键 between 10000 and 20000”流程也很顺先按上面的步骤找到主键10000所在的叶子节点这一步还是3次IO。因为叶子节点是双向链表直接顺着链表往后遍历就能依次拿到10001、10002……直到20000的所有数据不用再回上层节点查找后续只需要读取连续的叶子节点页IO效率很高。再总结下核心逻辑每个节点一个InnoDB页读一个页一次IO查数据要从根节点走到叶子节点经过的节点数树的高度所以IO次数树的高度。实际查询时上层节点根、中间常驻内存真正可能需要磁盘IO的只有最后一步读取叶子节点这也是B树高效的关键。整个流程的核心是“二分查找定位指针逐层向下”因为每个节点都是有序的二分查找能快速缩小范围不用遍历所有数据。我认为理解这个流程后就能明白为啥索引高度越低越好——高度3能存3000多万行只需要最多3次IO高度4要存45亿行才多1次IO但就是这1次IO可能因为中间节点无法全部缓存导致性能下降。这也是为啥不建议单表数据量超亿级的核心原因之一。