建设银行永泰支行网站产品设计和视觉传达设计哪个好

建设银行永泰支行网站,产品设计和视觉传达设计哪个好,wordpress菜单实现下拉,常州seo建站1、前言 很多人说#xff0c;MySQL每张表最好不要超过2000万条数据#xff0c;否则就会导致性能下降。阿里的Java开发手册上也提出#xff1a;单表行数超过 500 万行或者单表容量超过 2GB#xff0c;才推荐进行分库分表。 但实际上#xff0c;这个2000万或者500万都只是…1、前言很多人说MySQL每张表最好不要超过2000万条数据否则就会导致性能下降。阿里的Java开发手册上也提出单表行数超过 500 万行或者单表容量超过 2GB才推荐进行分库分表。但实际上这个2000万或者500万都只是一个大概的数字并不适用于所有场景如果盲目的以为表数据只要不超过2000万条就没问题了很可能会导致系统的性能大幅下降。实际情况下每张表由于自身的字段不同、字段所占用的空间不同等原因它们在最佳性能下可以存放的数据量也就不同。那么该如何计算出每张表适合的数据量呢别急慢慢往下看。2、本文适合的读者阅读本文你需要有一定的MySQL基础最好对InnoDB和B树都有一定的了解可能需要有一年以上的MySQL学习经验大概一年知道 “InnoDB中B树的高度一般保持在三层以内会比较好” 这条理论知识。本文主要是针对 “InnoDB中高度为3的B树最多可以存多少数据” 这一话题进行讲解的。且本文对数据的计算比较严格至少比网上95%以上的相关博文都要严格如果你比较在意这些细节并且目前不太清楚的话请继续往下阅读。阅读本文你大概需要花费10-20分钟的时间如果你在阅读的过程中对数据进行验算的话可能要花费30分钟左右。3、本文思维导图4、基础知识快速回顾众所周知MySQL中InnoDB的存储结构是B树B树大家都熟悉吧特性大概有以下几点一起快速回顾一下吧注下面这这些内容都是精华看不懂或者不理解的同学建议先收藏本文之后有知识基础了再回来看。一张数据表一般对应一颗或多颗树的存储树的数量与建索引的数量有关每个索引都会有一颗单独的树。聚簇索引和非聚簇索引主键索引也是聚簇索引非主键索引都是非聚簇索引。除格式信息外两种索引的非叶子节点都是只存索引数据的比如索引为id那非叶子节点就是存的id数据。叶子节点的区别如下聚簇索引的叶子节点一般情况下存的是这条数据的所有字段信息。所以我们select * from table where id 1的时候都是要去叶子节点拿数据的。非聚簇索引的叶子节点存的是这条数据所对应的主键和索引列信息。比如这条非聚簇索引是username然后表的主键是id那该非聚簇索引的叶子节点存的就是 username 和 id而不存其他字段。 相当于是先从非聚簇索引查到主键的值再根据主键索引去查数据内容一般情况下要查两次除非索引覆盖这也称之为回表就有点类似于存了个指针指向了数据存放的真实地址。B树的查询是从上往下一层层查询的一般情况下我们认为B树的高度保持在3层以内是比较好的也就是上两层是索引最后一层存数据这样查表的时候只需要进行3次磁盘IO就可以了(实际上会少一次因为根节点会常驻内存)且能够存放的数据量也比较可观。如果数据量过大导致B数变成4层了则每次查询就需要进行4次磁盘IO了从而使性能下降。所以我们才会去计算InnoDB的3层B树最多可以存多少条数据。MySQL每个节点大小默认为16KB也就是每个节点最多存16KB的数据可以修改最大64KB最小4KB。扩展那如果某一行的数据特别大超过了节点的大小怎么办MySQL5.7文档的解释是对于 4KB、8KB、16KB 和 32KB设置 最大行长度略小于数据库页面的一半 。例如对于默认的 16KB页大小最大行长度略小于 8KB 默认32KB的页大小则最大行长度略小于16KB。而对于 64KB 页面最大行则长度略小于 16KB。如果行超过最大行长度 则将可变长度列用外部页存储直到该行符合最大行长度限制。就是说把varchar、text这种长度可变的存到外部页中来减小这一行的数据长度。文档地址MySQL :: MySQL 5.7 Reference Manual :: 14.12.2 File Space ManagementMySQL查询速度主要取决于磁盘的读写速度因为MySQL查询的时候每次只读取一个节点到内存中通过这个节点的数据找到下一个要读取的节点位置再读取下一个节点的数据直到查询到需要的数据或者发现数据不存在。肯定有人要问了每个节点内的数据难道不用查询吗这里的耗时怎么不计算这是因为读取完整个节点的数据后会存到内存当中在内存中查询节点数据的耗时其实是很短的再配合MySQL的查询方式时间复杂度差不多为 O(log2N)O(log_2N)O(log2​N) 相比磁盘IO来说可以忽略不计。5、MySQL InnoDB 节点的储存内容在Innodb的B树中我们常说的节点被称之为页(page)每个页当中存储了用户数据所有的页合在一起组成了一颗B树当然实际会复杂很多但我们只是要计算可以存多少条数据所以姑且可以这么理解。页是InnoDB存储引擎管理数据库的最小磁盘单位我们常说每个节点16KB其实就是指每页的大小为16KB。这16KB的空间里面需要存储页格式信息和行格式信息其中行格式信息当中又包含一些元数据和用户数据。所以我们在计算的时候要把这些数据的都计算在内。页格式每一页的基本格式也就是每一页都会包含的一些信息总结表格如下名称空间含义和作用等File Header38字节文件头用来记录页的一些头信息。包括校验和、页号、前后节点的两个指针、页的类型、表空间等。Page Header56字节页头用来记录页的状态信息。包括页目录的槽数、空闲空间的地址、本页的记录数、已删除的记录所占用的字节数等。Infimum supremum26字节用来限定当前页记录的边界值包含一个最小值和一个最大值。User Records不固定用户记录我们插入的数据就存储在这里。Free Space不固定空闲空间用户记录增加的时候从这里取空间。Page Directort不固定页目录用来存储页当中用户数据的位置信息。每个槽会放4-8条用户数据的位置一个槽占用1-2个字节当一个槽位超过8条数据的时候会自动分成两个槽。File Trailer8字节文件结尾信息主要是用来校验页面完整性的。示意图页格式这块的内容我在官网翻了好久硬是没找到。。。。不知道是没写还是我眼瞎有找到的朋友希望可以在评论区帮我挂出来。所以上面页格式的表格内容主要是基于一些博客中学习总结的。另外当新记录插入到 InnoDB 聚集索引中时InnoDB 会尝试留出 1/16 的页面空闲以供将来插入和更新索引记录。如果按顺序升序或降序插入索引记录则生成的页大约可用 15/16 的空间。如果以随机顺序插入记录则页大约可用 1/2 到 15/16 的空间。参考文档MySQL :: MySQL 5.7 Reference Manual :: 14.6.2.2 The Physical Structure of an InnoDB Index除了User Records和Free Space以外所占用的内存是 385626812838 56 26 8 1283856268128 字节每一页留给用户数据的空间就还剩 16×1516×1024−1281523216 \times \frac{15}{16} \times 1024 - 128 1523216×1615​×1024−12815232 字节保留了1/16。当然这是最小值因为我们没有考虑页目录。页目录留在后面根据再去考虑这个得根据表字段来计算。行格式首先我觉得有必要提一嘴MySQL5.6的默认行格式为COMPACT(紧凑)5.7及以后的默认行格式为DYNAMIC(动态)不同的行格式存储的方式也是有区别的还有其他的两种行格式本文后续的内容主要是基于DYNAMIC(动态)进行讲解的。官方文档链接MySQL :: MySQL 5.7 参考手册 :: 14.11 InnoDB 行格式包括下面的行格式内容大都可以在里面找到每行记录都包含以下这些信息其中大都是可以从官方文档当中找到的。我这里写的不是特别详细仅写了一些能够我们计算空间的知识更详细内容可以去网上搜索 “MySQL 行格式”。名称空间含义和作用等行记录头信息5字节行记录的标头信息包含了一些标志位、数据类型等信息如删除标志、最小记录标志、排序记录、数据类型、页中下一条记录的位置等可变长度字段列表不固定来保存那些可变长度的字段占用的字节数比如varchar、text、blob等。若变长字段的长度小于 255字节就用1字节表示若大于 255字节用2字节表示。表字段中有几个可变长字段该列表中就有几个值如果没有就不存。null值列表不固定用来存储可以为null的字段是否为null。每个可为null的字段在这里占用一个bit就是bitmap的思想。该列表占用的空间是以字节为单位增长的例如如果有 9 到 16 个可以为null的列则使用两个字节没有占用1.5字节这种情况。事务ID和指针字段67字节了解MVCC的朋友应该都知道数据行中包含了一个6字节的事务ID和一个7字节的回滚指针。如果没有定义主键则还会多一个6字节的行ID字段当然我们都有主键所以这个行ID我们不计算。实际数据不固定这部分就是我们真实的数据了。示意图另外还有几点需要注意溢出页外部页的存储注意这一点是DYNAMIC的特性。当使用 DYNAMIC 创建表时InnoDB 会将较长的可变长度列比如 VARCHAR、VARBINARY、BLOB 和 TEXT 类型的值剥离出来存储到一个溢出页上只在该列上保留一个 20 字节的指针指向溢出页。而 COMPACT 行格式MySQL5.6默认格式则是将前 768 个字节和 20 字节的指针存储在 B 树节点的记录中其余部分存储在溢出页上。列是否存储在页外取决于页大小和行的总大小。当一行太长时选择最长的列进行页外存储直到聚集索引记录适合 B 树页文档里没说具体是多少。小于或等于 40 字节的 TEXT 和 BLOB 直接存储在行内不会分页。优点DYNAMIC 行格式避免了用大量数据填充 B 树节点从而导致长列的问题。DYNAMIC 行格式的想法是如果长数据值的一部分存储在页外则通常将整个值存储在页外是最有效的。使用 DYNAMIC 格式较短的列会尽可能保留在 B 树节点中从而最大限度地减少给定行所需的溢出页数。字符编码不同情况下的存储char 、varchar、text 等需要设置字符编码的类型在计算所占用空间时需要考虑不同编码所占用的空间。varchar、text等类型会有长度字段列表来记录他们所占用的长度但char是固定长度的类型情况比较特殊假设字段 name 的类型为 char(10) 则有以下情况对于长度固定的字符编码比如ASCII码字段 name 将以固定长度格式存储ASCII码每个字符占一个字节那 name 就是占用 10 个字节。对于长度不固定的字符编码比如utf8mb4至少将为 name 保留 10 个字节。如果可以InnoDB会通过修剪尾部空格空间的方式来将其存到 10 个字节中。如果空格剪完了还存不下则将尾随空格修剪为列值字节长度的最小值一般是 1 字节。列的最大长度为 字符编码的最大字符长度×N字符编码的最大字符长度 \times N字符编码的最大字符长度×N比如 name 字段的编码为 utf8mb4那就是 4×104 \times 104×10。大于或等于 768 字节的 char 列会被看成是可变长度字段就像varchar一样可以跨页存储。例如utf8mb4 字符集的最大字节长度为 4则 char(255) 列将可能会超过 768 个字节进行跨页存储。说实话对char的这个设计我是不太理解的尽管看了很久包括官方文档和一些博客希望懂的同学可以在评论区解惑对于长度不固定的字符编码这块char是不是有点像是一个长度可变的类型了我们常用的 utf8mb4占用为 1 ~ 4 字节那么 char(10) 所占用的空间就是 10 ~ 40 字节这个变化还是挺大的啊但是它并没有留足够的空间给它也没有使用可变长度字段列表去记录char字段的空间占用情况就很特殊6、开始计算好了我们已经知道每一页当中具体存储的东西了现在我们已经具备计算能力了。由于页的剩余空间我已经在上面页格式的地方计算过了每页会剩余 15232 字节可用下面我们直接计算行。6.1 非叶子节点计算单个节点计算索引页就是存索引的节点也就是非叶子节点。每一条索引记录当中都包含了当前索引的值、一个 6字节 的指针信息、一个 5 字节的行标头用来指向下一层数据页的指针。索引记录当中的指针占用空间我没在官方文档里找到这个 6 字节是我参考其他博文的他们说源码里写的是6字节但具体在哪一段源码我也不知道。希望知道的同学可以在评论区解惑。假设我们的主键id为 bigint 型也就是8个字节那索引页中每行数据占用的空间就等于 865198 6 5 1986519 字节。每页可以存 15232÷19≈80115232 \div 19 \approx 80115232÷19≈801 条索引数据。那算上页目录的话按每个槽平均6条数据计算的话至少有 801÷6≈134801 \div 6 \approx 134801÷6≈134 个槽需要占用 268 字节的空间。把存数据的空间分一点给槽的话我算出来大约可以存 787 条索引数据。如果是主键是 int 型的话那可以存更多大约有 993 条索引数据。前两层非叶子节点计算在 B 树当中当一个节点索引记录为 NNN 条时它就会有 NNN 个子节点。由于我们 3 层B树的前两层都是索引记录第一层根节点有 NNN 条索引记录那第二层就会有 NNN 个节点每个节点数据类型与根节点一致仍然可以再存 NNN 条记录第三层的节点个数就会等于 N2N^2N2。则有主键为 bigint 的表可以存放 7872619369787 ^ 2 6193697872619369 个叶子节点主键为 int 的表可以存放 9932986049993 ^ 2 9860499932986049 个叶子节点OK计算完毕。6.2 数据条数计算最少存放记录数前面我们提到最大行长度略小于数据库页面的一半之所以是略小于一半是由于每个页面还留了点空间给页格式的其他内容所以我们可以认为每个页面最少能放两条数据每条数据略小于8KB。如果某行的数据长度超过这个值那InnoDB肯定会分一些数据到溢出页当中去了所以我们不考虑。那每条数据8KB的话每个叶子节点就只能存放 2 条数据这样的一张表在主键为 bigint 的情况下只能存放 2×61936912387382 \times 619369 12387382×6193691238738 条数据也就是一百二十多万条这个数据量没想到吧。较多的存放记录数假设我们的表是这样的sql体验AI代码助手代码解读复制代码-- 这是一张非常普通的课程安排表除id外仅包含了课程id和老师id两个字段 -- 且这几个字段均为 int 型当然实际生产中不会这么设计表这里只是举例。 CREATE TABLE course_schedule ( id int NOT NULL, teacher_id int NOT NULL, course_id int NOT NULL, PRIMARY KEY (id) USING BTREE ) ENGINEInnoDB DEFAULT CHARSETutf8;先来分析一下这张表的行数据无null值列表无可变长字段列表需要算上事务ID和指针字段需要算上行记录头那么每行数据所占用的空间就是 444675304 4 4 6 7 5 3044467530 字节每个叶子节点可以存放 15232÷30≈50715232 \div 30 \approx 50715232÷30≈507 条数据。算上页目录的槽位所占空间每个叶子节点可以存放 502 条数据那么三层B树可以存放的最大数据量就是 502×986049494,996,598502 \times 986049 494,996,598502×986049494,996,598将近5亿条数据没想到吧。常规表的存放记录数大部分情况下我们的表字段都不是上面那样的所以我选择了一场比较常规的表来进行分析看看能存放多少数据。表情况如下sql体验AI代码助手代码解读复制代码CREATE TABLE blog ( id bigint unsigned NOT NULL AUTO_INCREMENT COMMENT 博客id, author_id bigint unsigned NOT NULL COMMENT 作者id, title varchar(50) CHARACTER SET utf8mb4 NOT NULL COMMENT 标题, description varchar(250) CHARACTER SET utf8mb4 NOT NULL COMMENT 描述, school_code bigint unsigned DEFAULT NULL COMMENT 院校代码, cover_image char(32) DEFAULT NULL COMMENT 封面图, create_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间, release_time datetime DEFAULT NULL COMMENT 首次发表时间, modified_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT 修改时间, status tinyint unsigned NOT NULL COMMENT 发表状态, is_delete tinyint unsigned NOT NULL DEFAULT 0, PRIMARY KEY (id), KEY author_id (author_id), KEY school_code (school_code) USING BTREE ) ENGINEInnoDB AUTO_INCREMENT1 DEFAULT CHARSETutf8 COLLATEutf8_general_mysql500_ci ROW_FORMATDYNAMIC;这是我的开源项目“校园博客”GitHub地址github.com/stick-i/scb… 中的博客表用于存放博客的基本数据。分析一下这张表的行记录行记录头信息肯定得有占用5字节。可变长度字段列表表中title占用1字节description占用2字节共3字节。null值列表表中仅school_code、cover_image、release_time3个字段可为null故仅占用1字节。事务ID和指针字段两个都得有占用13字节。字段内容信息id、author_id、school_code均为bigint型各占用8字节共24字节。create_time、release_time、modified_time均为datetime类型各占8字节共24字节。status、is_delete为tinyint类型各占用1字节共2字节。cover_image为char(32)字符编码为表默认值utf8由于该字段实际存的内容仅为英文字母存url的结合前面讲的字符编码不同情况下的存储故仅占用32字节。title、description分别为varchar(50)、varchar(250)这两个应该都不会产生溢出页不太确定字符编码均为utf8mb4实际生产中70%以上都是存的中文(3字节)25%为英文(1字节)还有5%为4字节的表情则存满的情况下将占用 (50250)×(0.7×30.25×10.05×4)765(50 250) \times (0.7 \times 3 0.25 \times 1 0.05 \times 4 ) 765(50250)×(0.7×30.25×10.05×4)765 字节。统计上面的所有分析共占用 869 字节则每个叶子节点可以存放 15232÷869≈1715232 \div 869 \approx 1715232÷869≈17 条算上页目录仍然能放 17 条。则三层B树可以存放的最大数据量就是 17×61936910,529,27317 \times 619369 10,529,27317×61936910,529,273约一千万条数据再次没想到吧。6.3 数据计算总结根据上面三种不同情况下的计算可以看出InnoDB三层B树情况下的数据存储量范围为一百二十多万条到将近5亿条这个跨度还是非常大的同时我们也计算了一张博客信息表可以存储约一千万条数据。所以啊我们在做项目考虑分表的时候还是得多关注一下表的实际情况而不是盲目的认为两千万数据就是那个临界点。如果面试时谈到这块的问题我想面试官也并不是想知道这个数字到底是多少而是想看你如何分析这个问题看你得出这个数字的过程。如果本文中有任何写的不对的地方欢迎各位朋友在评论区指正。7、写在后面的一些话这篇文章写了整整两周虽然第一周在划水真的超级干货了前前后后查了好多资料也看了好多博文官方文档有些地方写的确实含糊我看了好久都没看懂。学到知识的小伙伴请一定要给我点个赞啊。最后分享一下我在项目中提到的那个开源项目“校园博客”GitHub地址github.com/stick-i/scb…项目的技术栈主要是后端 Java SpringBoot SpringCloud Nacos Getaway Fegin MybatisPlus MySQL Redis ES RabbitMQ Minio 七牛云OSS Jenkins Docker前端 Vue2 ElementUI Axios目前项目还有很大改进和完善的空间欢迎各位有意愿的同学参与项目贡献目前特缺前端一起学习一起进步。