索引

我们都知道，骆驼祥子是老舍的一部优秀的长篇小说，在初中阶段我们都学习过吧，那么今天， 我就以骆驼祥子为例，来分析一下2018年在建站的过程中，对于数据库和索引技术方面，百度和谷歌等搜索巨头有哪些变化，以此来帮助我们更好的优化数据库结构，少走一些弯路。 博客程序我是接触的比较早的，可能是因为我是小白，在技术方面没有什么强项，因此在建站的过程中，我一般都采用博客程序，当然了，你可以选择ZLBOG或者wordpress都可以，这两款程序系统是我比较喜欢用的，不过我不喜欢用PHP建站，因为技术方面存在一些难题，尤其是配合MYSQL数据库问题上。 好了，下面说些实在点儿的，首先是环境配置问题，关注程序、系统、数据库、站点主题方面的。 我的博客是用ZBLOG建设的，取名叫百家笔记网，程序方面选择的是非常成熟的ASP语言，数据库嘛，还是喜欢界面性的比较适合我们操作，因此用了微软的sql server2008版本，这个版本比较成熟，之前我也分析过，关于2008版本以后的数据库都存在缓存重启服务器后会导致自增字段跳跃1000及10000数值的毛病，这对于我们博客来说，本来数据库就不多，一下子跳跃这么大，是很头疼的。以“骆驼祥子http://www.simayi.net/dushubiji/896.html好词好句读书笔记摘抄”为例，这是我在2018年2月23日发布的一篇文章，但是在搜索上的表现比较好

目录 一、优化概述 二、查询与索引优化分析 1性能瓶颈定位 Show命令 慢查询日志 explain分析查询 profiling分析查询 2索引及查询优化 三、配置优化 1) max_connections 2) back_log 3) interactive_timeout 4) key_buffer_size 5) query_cache_size 6) record_buffer_size 7) read_rnd_buffer_size 8) sort_buffer_size 9) join_buffer_size 10) table_cache 11) max_heap_table_size 12) tmp_table_size 13) thread_cache_size 14) thread_concurrency 15) wait_timeout 一、 优化概述 MySQL数据库是常见的两个瓶颈是CPU和I/O的瓶颈，CPU在饱和的时候一般发生在数据装入内存或从磁盘上读取数据时候。磁盘I/O瓶颈发生在装入数据远大于内存容量的时候，如果应用分布在网络上，那么查询量相当大的时候那么平瓶颈就会出现在网络上，我们可以用mpstat, iostat, sar和vmstat来查看系统的性能状态。 除了服务器硬件的性能瓶颈，对于MySQL系统本身，我们可以使用工具来优化数据库的性能

13.4. 向数据库中添加记录 我们第一次填充数据库时可能需要做大量的表插入。 下面是一些建议，可以尽可能高效地处理这些事情。 13.4.1. 关闭自动提交 关闭自动提交，并且只在每次（数据拷贝）结束的时候做一次提交 。 （在纯 SQL 里，这就意味着在开始的时候发出 BEGIN， 并且在结束的时候执行 COMMIT。有些客户端的库可能背着你干这些事情， 这种情况下你必须确信只有在你要那些库干这些事情的时候它才做。） 如果你允许每个插入都独立地提交，那么 PostgreSQL 会为所增加的每行记录做大量的处理。 在一个事务里完成所有插入的动作的最大的好处就是，如果有一条记录插入失败， 那么，到该点为止的所有已插入记录都将被回滚，这样你就不会很难受地面对一个只装载了一部分数据的表。 13.4.2. 使用 COPY 使用 COPY 在一条命令里装载所有记录， 而不是一连串的INSERT命令。COPY 命令是为装载数量巨大的数据行优化过的； 它没 INSERT 那么灵活，但是在大量装载数据的情况下，导致的过荷也少很多。 因为 COPY 是单条命令，因此填充表的时候就没有必要关闭自动提交了。 如果你不能使用 COPY，那么 使用 PREPARE 来创建一个准备好的 INSERT， 然后使用 EXECUTE 多次效率更高。 这样就避免了重复分析和规划 INSERT 的开销。 请注意，

在pandas中怎么样实现类似mysql查找语句的功能： select * from table where column_name = some_value; pandas中获取数据的有以下几种方法： 布尔索引 位置索引 标签索引 使用API 假设数据如下: import pandas as pd import numpy as np df = pd.DataFrame({'A': 'foo bar foo bar foo bar foo foo'.split(), 'B': 'one one two three two two one three'.split(), 'C': np.arange(8), 'D': np.arange(8) * 2}) 布尔索引 该方法其实就是找出每一行中符合条件的真值(true value)，如找出列A中所有值等于foo df[df['A'] == 'foo'] # 判断等式是否成立 位置索引 使用iloc方法，根据索引的位置来查找数据的。这个例子需要先找出符合条件的行所在位置 mask = df['A'] == 'foo' pos = np.flatnonzero(mask) # 返回的是array([0, 2, 4, 6, 7]) df.iloc[pos] #常见的iloc用法 df.iloc[:3,1:3] 标签索引

最近一段时间在研究数据库的分布式部署，但是并不是所有的数据库本身都支持分布式，那么怎么办呢。 本人自己没有用过分布式的数据库，根据自己的想到一种简单分布式的架构，来进行分布式的部署。 现在先上图， 大概的想法是在数据库外面多加一次 分布式引擎和引擎数据库，来实现对多个数据库的管理， 首先我们来说一下此种方案的 可行性 ，它是基于原来数据库的基础上在搭建平行的数据库来分摊压力，而分布式引擎的作用则是处理主程序对数据库的请求，并返回请求的结果的， 此种方案的难点和核心点在于分库，依据什么来分库会影响到最终搭建成的系统的运行效率，一个好的依据可以把原来的压力平均分摊给各个数据库（ 最好情况 ），而一个差的依据会导致压力集中到分布式引擎，导致压力剧增，运行效率和承受压力比原来还大， 在下以为分库的依据有以下几点需要注意的地方， 1.分开的数据库数据要平均，尽量每个数据库的数据量是相近的。 2. 面向客户的数据尽量是连续，即主程序一次查询出来面向客户的数据是从1个或者2个数据库就能查询出来的，也不是是1个表的数据只存在其中的一个数据库中，而是面向客户的数据只是查询分页的20条至50条直接，要尽量保证这些数据是在1个数据库就能全取出来的。 3.有业务关联性的数据最好都放在一个数据库中，比如这是一个管理系统，那么本系统的流程中的所有相关数据最好是放在一个库中。 4

一、AI文件结构说明 AI文件整体结构类似于PDF结构，主要由开头描述部分、间接对象、交叉索引表、文件尾部组成，主要结构如下图1所示，其中交叉索引表保存了所有obj在文件中的偏移地址，所有数据信息都保存在obj中，每个obj对象都类似于下面结构： 1 0 obj 数据 endobj ，交叉索引表以单行字符串Startxref开始。 Comments Objm Objn …… xref Trailer(rootIndex) startxref %%EOF 图 1 注： 1. Startxref包含间接对象交叉索引表文件偏移地址 2. Xref按行列出了所有间接对象的文件偏移地址 3. Trailer(rootIndex)，给出文件信息，包括root根目录对象索引，Infor目录对象索引，间接对象总个数 4. Comments文档开始 %PDF-1.5 5. 中间Obj部分为间接对象，对象顺序是交叉的 二、 AI文件内容格式说明： ID line Comments Prolog Scripts Setup Objects Layer1 Layer2 ……. Page Trailer %%EOF 注：以上数据按照先后顺序 分块 存储在文件AIPrivateData对应的Obj中，其中Obj数据长度最大为65536字节,数据可以分为：压缩（文本文件）、非压缩。 同时AI的图层信息、路径数据

limit 查询导出优化 耗时本质 mysql大数据量使用limit分页，随着页码的增大，查询效率越低下。 当一个表数据有几百万的数据的时候成了问题！ 如 select * from table limit 0,10 这个没有问题 当 limit 200000,10 的时候数据读取就很慢 原因本质： 1）limit语句的查询时间与起始记录（offset）的位置成正比 2）mysql的limit语句是很方便，但是对记录很多:百万，千万级别的表并不适合直接使用。 例如： limit10000,20的意思扫描满足条件的10020行，扔掉前面的10000行，返回最后的20行，问题就在这里。 ​ LIMIT 2000000, 30 扫描了200万+ 30行，怪不得慢的都堵死了，甚至会导致磁盘io 100%消耗。 ​ 但是: limit 30 这样的语句仅仅扫描30行。 优化手段 干掉或者利用 limit offset,size 中的offset 不是直接使用limit，而是首先获取到offset的id然后直接使用limit size来获取数据 对limit分页问题的性能优化方法 利用表的覆盖索引来加速分页查询 覆盖索引: 就是select 的数据列只用从索引中就能获得，不必读取数据行。mysql 可以利用索引返回select列表中的字段，而不必根据索引再次读取数据文件，换句话说：

01 引言 随着用户的增长、业务的发展，大型企业用户的业务系统的数据量越来越大，超大数据表的性能问题成为阻碍业务功能实现的一大障碍。其中，流水表作为最常见的一类超大表，是企业级用户经常碰到的性能瓶颈。 本文就以流水类的超大表，探讨基于SequoiaDB巨杉数据库存储的超大表进行的性能调优。SequoiaDB 巨杉数据库，作为新一代 OLTP 的分布式数据库，被广泛使用于海量数据存储与高并发操作场景中。对于海量数据的存储和高并发操作，分布式数据库相较于传统数据库有着天然的优势，合理利用SequoiaDB巨杉数据库多种特性，轻松解决超大表的性能问题。 02 数据存储规划很重要 对于流水类超大表，前期的数据存储规划尤为重要，合理的数据存储规划能有效利用数据库集群硬件资源，提供更高性能、更高效率的数据服务。 1. 集群规模评估与硬件配置搭配 在数据库集群规划伊始，需要通过调研数据库集群支撑应用规模、系统定位和业务长期发展规划进行摸底，用以评估集群规模以及各服务器的CPU、内存、硬盘、网卡的合理搭配。 精准的评估一个数据库集群规模，是一个宏大且复杂的综合工程，需要有的业务需求评估数据加以支持。通常情况下，由于业务需求变化快、业务增长普遍高于预期，小集群规划可以按照业务调研信息的1.5~2倍进行评估，大集群规划可以按1~1.5倍进行评估。 集群规模需要通过业务规模、数据存储规模

自从两年前了解到的索引以来的，就一直想写一篇有关索引的文章。然而我是个拖延癌症患者，一拖就是两年，不愧是我。该篇文章算是自己的笔记，欢迎批评。 概述 索引是什么？很多书和文章都会使用图书的目录来类比。目录的目的就是用方便我们查找具体内容的位置，具体的章节的范围。与此类似，MySQL中索引的用途是帮助我们加速查询以及排序。 在InnoDB中的索引类型有哈希索引、B+树索引、全文索引。哈希索引在InnoDB中设计为自适应的，不展开讨论。在InnoDB1.12之后有了全文索引，也是应用倒排，还没踩过坑(据说不支持中文)，有时间可以研究一下。 本篇主要讨论B+树索引。 B+树 学习MySQL的索引，必须得先了解其原理，否则很多问题将一头雾水。下文将讲述索引数据结构的原理，而不涉及其复杂的具体实现。 在谈B+树之前，不妨先思考，为什么索引能加快查询？为什么要用B+树作为索引而不用B树？哈希索引查询复杂度为O(1)为什么又不用哈希索引？ BST和AVL 在了解B树和B+树之前，先了解一下二叉搜索树(BST)和平衡二叉树(AVL)。 在顺序存储结构中(如数组)，最快的情况是第一个就是目标值，最坏的情况是最后一个是目标值，假设有n个元素，用大O标记法平均的时间复杂度为O(n)。 使用二叉搜索树可以有效的优化搜索时间。利用二叉搜索树的特性左子节点比父节点小、右子节点比父节点大

在SQL Server中，存储数据的最小单位是页，每一页所能容纳的数据为8060字节.而页的组织方式是通过B树结构（表上没有聚集索引则为堆结构，不在本文讨论之列)如下图: 在聚集索引B树中，只有叶子节点实际存储数据，而其他根节点和中间节点仅仅用于存放查找叶子节点的数据. 每一个叶子节点为一页，每页是不可分割的. 而SQL Server向每个页内存储数据的最小单位是表的行(Row).当叶子节点中新插入的行或更新的行使得叶子节点无法容纳当前更新或者插入的行时，分页就产生了.在分页的过程中，就会产生碎片. 理解外部碎片 首先，理解外部碎片的这个“外”是相对页面来说的。外部碎片指的是由于分页而产生的碎片.比如，我想在现有的聚集索引中插入一行，这行正好导致现有的页空间无法满足容纳新的行。从而导致了分页: 因为在SQL SERVER中，新的页是随着数据的增长不断产生的，而聚集索引要求行之间连续，所以很多情况下分页后和原来的页在磁盘上并不连续. 这就是所谓的外部碎片. 由于分页会导致数据在页之间的移动，所以如果插入更新等操作经常需要导致分页，则会大大提升IO消耗，造成性能下降. 而对于查找来说，在有特定搜索条件，比如where子句有很细的限制或者返回无序结果集时，外部碎片并不会对性能产生影响。但如果要返回扫描聚集索引而查找连续页面时,外部碎片就会产生性能上的影响. 在SQL Server中