索引

一、 表设计规范 库名、表名、字段名必须使用小写字母，“_”分割。 库名、表名、字段名必须不超过12个字符。 库名、表名、字段名见名知意,建议使用名词而不是动词。 建议使用InnoDB存储引擎。 存储精确浮点数必须使用DECIMAL替代FLOAT和DOUBLE。 建议使用UNSIGNED存储非负数值。 建议使用INT UNSIGNED存储IPV4。 整形定义中不添加长度，比如使用INT，而不是INT(4)。 使用短数据类型，比如取值范围为0-80时，使用TINYINT UNSIGNED。 不建议使用ENUM类型，使用TINYINT来代替。 尽可能不使用TEXT、BLOB类型。 VARCHAR(N)，N表示的是字符数不是字节数，比如VARCHAR(255)，可以最大可存储255个汉字，需要根据实际的宽度来选择N。 VARCHAR(N)，N尽可能小，因为MySQL一个表中所有的VARCHAR字段最大长度是65535个字节，进行排序和创建临时表一类的内存操作时，会使用N的长度申请内存。 表字符集选择UTF8。 使用VARBINARY存储变长字符串。 存储年使用YEAR类型。 存储日期使用DATE类型。 存储时间（精确到秒）建议使用TIMESTAMP类型，因为TIMESTAMP使用4字节，DATETIME使用8个字节。 建议字段定义为NOT NULL。 将过大字段拆分到其他表中。

存储引擎都是作用在表上的 MyISAM索引文件和数据文件是分离的（非聚集）最终一个表会形成3个文件 例如表名叫 aa,形成的3个文件分别叫aa.frm(存储表的结构信息，就是有哪些字段等信息)，aa.MYD(存储数据)，aa.MYI(存储索引文件) InnoDB索引实现（聚集） InnoDB的表最终会形成2个文件，bb.frm(存储表的结构信息，就是有哪些字段等信息),bb.idb(索引和数据) 来源： CSDN 作者： softwareDragon 链接： https://blog.csdn.net/qq_33348135/article/details/104435383

Hbase 作为列族 数据库 最经常被人诟病的特性包括：无法轻易建立“二级索引”，难以执行求和、计数、排序等操作。比如，在旧版本的(<0.92)Hbase中， 统计数据表 的总行数，需要使用Counter方法，执行一次MapReduce Job才能得到。虽然HBase在 数据存储层 中集成了MapReduce，能够有效用于数据表的分布式计算。然而在很多情况下，做一些简单的相加或者聚合计算的时候，如果直接将计算过程放置在server端，能够减少通讯开销，从而获得很好的性能提升。于是，HBase在0.92之后引入了协处理器(coprocessors)，实现一些激动人心的新特性：能够轻易建立二次索引、复杂过滤器(谓词下推)以及访问控制等。 而华为二级索引是华为内部一个解决这个问题的方案。大致思路如下 ： 这个是华为的二级索引方案，已经开放源代码了,下面是网上的一篇讲解原理的帖子，发出来和大家共享一下。 经过本人认真阅读了一下代码，发现这个源码仅供参考，想要集成到原有的集群当中是有点儿难度的，它对hbase的源码进行不少的修改。 源码地址： https://github.com/Huawei-Hadoop/hindex 下面来对其方案做一个分析。 1.整体架构 这个架构在Client Ext中设定索引细节，在Balancer中收集信息，在Coprocessor中管理二级索引数据。 2

【删除不需要的列】 # 前置库：pandas # 删除不需要的列 DataFrame . drop ( columns = [ 'column_name' ] , inplace = True ) 【对某列数据进行Z-score标准化】 # 前置库：pandas # 对某列进行标准化 from sklearn . preprocessing import StandardScaler DataFrame [ 'column_name' ] = StandardScaler ( ) . fit_transform ( DataFrame [ 'column_name' ] . values . reshape ( - 1 , 1 ) ) 【有监督学习类数据target列的计数与可视化】 # 前置库：pandas # 对标签列进行观察，查看已标注样本各类别对数量 print ( pd . value_counts ( DataFrame [ 'target_column' ] , sort = True ) ) # 图形化展示 from matplotlib import pyplot as plt pd . value_counts ( DataFrame [ 'target_column' ] ) . plot ( kind = 'bar' ) plt . title (

一，什么是记录Record和PL/SQL表？ 记录Record：由单行多列的标量类型构成的临时记录对象类型。类似于多维数组。 PL/SQL表：由多行单列的索引列和可用列构成的临时索引表对象类型。类似于一维数组和键值对。 都是用户自定义数据类型。 二，Record + PL/SQL表 用途是什么？ Record + PL/SQL表可以进行数据的多行多列存储。这样我们就可使用Record + PL/SQL表在需要时封装一个临时的表对象，进行传递和操作。 通过Record自定义表结构，封装一条记录。PL/SQL表声明 可用列 类型 为Record类型（将可用列指向Record类型变量），每个索引对应一个Record类型变量。 三，使用Record + PL/SQL表进行数据的多行多列存储 ①声明Record类型和PL/SQL表， 其中PL/SQL表的索引列为主键约束和唯一约束列或自增Integer。可用列为Record类型或%RowType类型。 ②填充PL/SQL表可用列（Record类型）：通过索引指向Record，使用Record访问记录成员。 语法： PL/SQL表名(索引列值).记录成员 := 记录成员类型值； 或 PL/SQL表名(索引列值) := Record类型变量； --注意其PL/SQL表中声明的可用列要和这里赋值的Record类型变量结构一样 ③访问PL/SQL表

简述 什么时候没用 1.有or必全有索引; 2.复合索引未用左列字段; 3.like以%开头; 4.需要类型转换; 5.where中索引列有运算; 6.where中索引列使用了函数; 7.如果mysql觉得全表扫描更快时（数据少）; 什么时没必要用 1.唯一性差; 2.频繁更新的字段不用（更新索引消耗）; 3.where中不用的字段; 4.索引使用<>时，效果一般; 详述（转） 索引并不是时时都会生效的，比如以下几种情况，将导致索引失效： 如果条件中有or，即使其中有部分条件带索引也不会使用(这也是为什么尽量少用or的原因)，例子中user_id无索引 注意：要想使用or，又想让索引生效，只能将or条件中的每个列都加上索引 对于复合索引，如果不使用前列，后续列也将无法使用，类电话簿。 like查询是以%开头 存在索引列的数据类型隐形转换，则用不上索引，比如列类型是字符串，那一定要在条件中将数据使用引号引用起来,否则不使用索引 where 子句里对索引列上有数学运算，用不上索引 where 子句里对有索引列使用函数，用不上索引 如果mysql估计使用全表扫描要比使用索引快,则不使用索引 比如数据量极少的表 什么情况下不推荐使用索引？ 1) 数据唯一性差（一个字段的取值只有几种时）的字段不要使用索引 比如性别，只有两种可能数据。意味着索引的二叉树级别少，多是平级

前言 大家都知道索引对于数据访问的性能有非常关键的作用，都知道索引可以提高数据访问效率。 　　为什么索引能提高数据访问性能?他会不会有“副作用”?是不是索引创建越多，性能就越好?到底该如何设计索引，才能最大限度的发挥其效能? 　　这篇文章主要是带着上面这几个问题来做一个简要的分析，同时排除了业务场景所带来的特殊性，请不要纠结业务场景的影响。 索引为什么能提高数据访问性能? 　　很多人只知道索引能够提高数据库的性能，但并不是特别了解其原理，其实我们可以用一个生活中的示例来理解。 　　我们让一位不太懂计算机的朋友去图书馆确认一本叫做《MySQL性能调优与架构设计》的书是否在藏，这样对他说：“请帮我借一本计算机类的数据库书籍，是属于 MySQL 数据库范畴的，叫做《MySQL性能调优与架构设计》”。朋友会根据所属类别，前往存放“计算机”书籍区域的书架，然后再寻找“数据库”类存放位置，再找到一堆讲述“MySQL”的书籍，最后可能发现目标在藏(也可能已经借出不在书架上)。 　　在这个过程中： “计算机”->“数据库”->“MySQL”->“在藏”->《MySQL性能调优与架构设计》其实就是一个“根据索引查找数据”的典型案例，“计算机”->“数据库”->“MySQL”->“在藏” 就是朋友查找书籍的索引。 　　假设没有这个索引，那查找这本书的过程会变成怎样呢

mysql 大数据分页和索引使用 使用覆盖索引 一个表建立在id,create_time上建立了索引。 如下2个sql语句，执行时间一样。 因为查询字段id被索引覆盖。 select id from order_manage where create_time > '2014-01-01' order by create_time desc limit 100000,10 select a.id from order_manage a inner join ( select id from order_manage where create_time > '2014-01-01' order by create_time desc limit 1000,10) b on a.id = b.id 如下2条sql，使用inner join要快一个数量级。 inner join影响结果集仍然是$start +30,但是数据获取的过程（Sending data状态）发生在索引文件中，而不是数据表文件，这样所需要的系统开销就比前一种普通的查询低一个数量级，而主查询的影响结果集只有30条，几乎无开销。但是切记，这里仍然涉及了太多的影响结果集操作 其实也可以分成2条sql语句来做，第一条使用覆盖索引查询出id，在使用in查询出需要的字段数据。 select * from order_manage

　　设计好MySql的索引可以让你的数据库飞起来，大大的提高数据库效率。设计MySql索引的时候有一下几点注意： 　　1,创建索引 　　对于查询占主要的应用来说，索引显得尤为重要。很多时候性能问题很简单的就是因为我们忘了添加索引而造成的，或者说没有添加更为有效的索引导致。如果不加索引的话，那么查找任何哪怕只是一条特定的数据都会进行一次全表扫描，如果一张表的数据量很大而符合条件的结果又很少，那么不加索引会引起致命的性能下降。但是也不是什么情况都非得建索引不可，比如性别可能就只有两个值，建索引不仅没什么优势，还会影响到更新速度，这被称为过度索引。 　　2,复合索引 　　比如有一条语句是这样的：select * from users where area='beijing' and age=22; 　　如果我们是在area和age上分别创建单个索引的话，由于mysql查询每次只能使用一个索引，所以虽然这样已经相对不做索引时全表扫描提高了很多效率，但是如果在area、age两列上创建复合索引的话将带来更高的效率。如果我们创建了（area, age, salary）的复合索引，那么其实相当于创建了（area,age,salary）、（area,age）、（area）三个索引，这被称为最佳左前缀特性。因此我们在创建复合索引时应该将最常用作限制条件的列放在最左边，依次递减。 　　3

1. Mysql内核 MyISAM和InnoDB内核选型 1. InnoDB 支持事务，MyISAM 不支持事务。这是 MySQL 将默认存储引擎从 MyISAM 变成 InnoDB 的重要原因之一； 2. InnoDB 支持外键，而 MyISAM 不支持。对一个包含外键的 InnoDB 表转为 MYISAM 会失败； 3. InnoDB 是聚集索引，MyISAM 是非聚集索引。聚簇索引的文件存放在主键索引的叶子节点上，因此 InnoDB 必须要有主键，通过主键索引效率很高。但是辅助索引需要两次查询，先查询到主键，然后再通过主键查询到数据。因此，主键不应该过大，因为主键太大，其他索引也都会很大。而 MyISAM 是非聚集索引，数据文件是分离的，索引保存的是数据文件的指针。主键索引和辅助索引是独立的。 4. InnoDB 不保存表的具体行数，执行 select count(*) from table 时需要全表扫描。而MyISAM 用一个变量保存了整个表的行数，执行上述语句时只需要读出该变量即可，速度很快； 5. InnoDB 最小的锁粒度是行锁，MyISAM 最小的锁粒度是表锁。一个更新语句会锁住整张表，导致其他查询和更新都会被阻塞，因此并发访问受限。这也是 MySQL 将默认存储引擎从 MyISAM 变成 InnoDB 的重要原因之一； 如何选择： 1. 是否要支持事务