数据库索引创建需考虑因素

1数据量超过三百，理论上应创建索引

2经常与其他表链接的表，在链接字段应创建索引 on 两边的字段，都要建立索引

3经常出现在where子句中的字段，尤其是大表，应创建索引

4索引应创建在选择性高，重复度低的字段上，如员工表，姓名和性别都作为查询条件，姓名更适合建立索引。如果两个同时建立了索引，MySQL也会自动选择以姓名作为索引查询

5索引应该建立在小字段上，对于大的文本甚至超长字段，尽量不建立索引

6复合索引

① 正确选择复合索引中的主列字段，一般是选择性较好的字段

② 复合索引的几个字段是否经常同时以AND方式出现在Where子句中？单字段查询是否极少甚至没有？ 如果是，则可以建立复合索引；否则考虑单字段索引

③ 如果复合索引中包含的字段经常单独出现在Where子句中，则分解为多个单字段索引

④ 如果既有单字段索引，又有这几个字段上的复合索引，一般可以删除复合索引

7索引维护也需要成本，频繁增删的数据表，谨慎选择索引

7个因素决定大数据的复杂性 如何处理

 我们谈论了很多关于复杂数据及其为你的商业智能带来的挑战和机遇，但是导致数据复杂化的是什么呢？

以及你如何区分你的公司当前的数据是否是“复杂的”，亦或不久的将来会变得复杂？本文将解决这些问题。

为什么这很重要？

当你试图将数据转化为商业价值时，它的复杂度很可能会预示你将面对的困难程度——复杂数据的准备和分析通常要比简单数据更加困难，以及通常需要一组不同的BI 工具来实现。复杂数据在可以“成熟的”分析和可视化之前需要额外的准备工作和数据模型。因此重要的是，通过了解您目前的数据的复杂程度以及它在未来的复杂性趋向，来评估您的大数据/商业智能项目是否能够胜任这一任务。

简单测试：大数据或者异构数据

在高级层面上，有两种基本的迹象表明你的数据可能被视为是复杂的：

你的数据很“大”：我们把大放在引号里是因为它貌似符合“大数据”术语的含义。然而事实是，处理海量数据在计算资源需要处理巨大的数据集方面提出了一个挑战， 就像把小麦从谷壳分开的困难，或者说在一个巨大的原始信息中辨别信号和杂音。

你的数据来自许多不同的数据源：多重数据源通常意味着脏数据，或者遵循着不同的内部逻辑结构的简单的多个数据集。为了确保数据源有统一的数据语言，数据必须被转换或整合到一个中央资源库。

可以认为这是两个最初的（可供选择的）征兆：如果你正处理大数据或异构数据，你应当开始思考数据的复杂性。但是深究一下，对你的公司的数据的复杂性，以下有7个更具体的指标。

（注意，以上两点之间有相似之处，但不互相排除——反之，例如，离散数据往往意味着各种各样的数据结构类型）

7个因素决定你的数据的复杂性

1、数据结构

不同数据源的数据，或甚至来自同一个源的不同表，通常设计同样的信息但结构却完全不同：

举例来说，想象你们人力资源部有三种不同的表格，一个是员工个人信息表，另一个是员工职位和薪资表第三个是员工职位要求表，诸如此类——而你们财务部门随同保险、福利和其他花费一起记录同样的信息到单个表中。另外，在这些表中的一些表可能提到员工的全名，而另一些则只有名字的首字母，或者二者的结合。为了从所有表中有效使用数据，同时不丢失或重复信息，需要数据建模或准备工作。

这是最简单的用例：更进一步复杂化的是处理最初没有适当地模式的非结构化数据源（例如NoSQL 数据库）。

2、数据大小

再次回到模糊的“大数据”概念，你收集的数据量会影响你需要用来分析它的软硬件的类型。这个可以通过原始大小来衡量：字节，TB或PB——数据增长越大，越有可能“窒息”广泛使用的内存数据库（IMDB），依赖于转化压缩数据到服务器内存。其他因素包括多元异构数据——包含很多数据行的表（Excel，可以说是最常用的数据分析工具，最大行数限制为1048576行），或结构化数据——包含很多数据列的表。

你将会发现在分析工具和方法上用于分析100,000行数据和那些用于分析1亿行数据的是明显不同的。

3、数据细节

你想要探索的数据的粒度水平。当创建一个仪表盘或报表，展现总结或聚合数据时常常比让终端用户钻取到每一个细节更容易实现——然而这是以牺牲数据分析的深度和数据挖掘为代价而做的权宜之计。

创建一个BI系统，使其具有颗粒向海量数据钻取处理分析的能力，（不依赖于预定义查询，聚合或汇总表）

4、查询语言

不同的数据源有不同的数据语言：虽然SQL是从常见数据源和RDBMS提取数据的主要手段，但是当使用第三方平台时你会经常需要通过它自己的API和语法去连接它，以及解析用于访问数据的数据模型和协议。

你的BI工具需要足够灵活的根据数据源允许这种本地连接的方式，或者通过内置插件或API访问，否则你会发现你自己将不得不重复一个繁琐的导出数据到表格SQL数据库数据仓库的过程，然后导入到你的商业智能软件里，从而使你的分析变得麻烦。

5、数据类型

一方面动态数据以表格形式存储，处理的大多是数值型数据，但是大规模和非结构化的机器数据完全是另外一回事儿，就像是文字数据集存储在MongoDB中，当然了，更别提像视频音频这种超大规模的非结构化数据了。

不同的数据类型具有不同的规则，为使得商业决策建立在对公司数据的全面考虑的基础上，找到一种建立单一可信来源的方法是至关重要的。

6、离散数据

数据存储在多个位置：例如，组织里的不同部门，本地或云（付费存储或通过云应用），来自客户或供应商的外部数据等。这种数据不仅收集起来很困难（简单来说是由于及时而有效的接收数据而需要的利益相关者的数量）。而且一旦收集了——在不同的数据集交叉引用和分析之前，通常需要“清理”或标准化，因为每个本地数据集是根据相关组织应用程序自身的实际和关注收集数据。

7、数据量的增长

最终，你不仅需要考虑当前数据，还有数据的增长或变化的速度。如果经常更新数据源，或经常增加新的数据源，这将会消耗你的软硬件资源（无论何时当源数据发生重大更改时,不是非常先进的系统都需要重新获取整个数据集）,以及上述提到的关于结构、类型、大小的复合性问题等。

怎样掌控复杂数据？

如果你认同上述的一个或更多以及你的数据刚刚好是复杂的，不要绝望：理解，是找到一个合适的解决方案的第一步，以及复杂数据的分析本身不需要过于复杂。我们将在未来的文章中涉及解决复杂数据的方法，但是你将想问自己的第一件事可能是——控制复杂数据你实际需要多少BI系统。

以上是小编为大家分享的关于7个因素决定大数据的复杂性 如何处理的相关内容，更多信息可以关注环球青藤分享更多干货

范式书上讲解太拗口，自己总结一下：

第一范式：数据表中的每一列（每个字段）必须是不可拆分的最小单元,不允许存在隐藏字段,属性保持“原子性”（最大细分的二维表）

第二范式：第一范式基础上要有主键，所有列都必须依赖于主键，而不能有任何一列与主键没有关系，也就是说一个表只描述一件事情（相当于这行阐述的是一个人时，你不能加一列说明天气）

第三范式：满足第二范式，表中的每一列只与主键直接相关而不是间接相关，（表中的每一列只能依赖于主键）

正规化范式（BCDF）：所有表中的决定因素必须是一个候选键，如果只有一个候选键，那么就和第三范式是一样的。

有第四第五范式，更高的范式是为了解决数据冗余问题，但可以通过其他办法达到。所以一般用不到

五大约束：

1 primary KEY :设置主键约束；

2 UNIQUE ：设置唯一性约束，不能有重复值；

3 DEFAULT 默认值约束，height DOUBLE(3,2)DEFAULT 12 height不输入是默认为1,2

4 NOT NULL ：设置非空约束，该字段不能为空；

5 FOREIGN key :设置外键约束。

数据库作为整个系统的一部分，它的表现直接受服务器、 *** 作系统、存储、网络、应用程序中SQL语句的质量、数据库设计的质量、以及其它诸多因素的影响，这些因素加在一起非常复杂，经验起着非常重要的作用。因此一个好的数据库工程师除了知识作为基础，经验的多寡、见识的薄广，往往决定了是否合格与优秀。

优秀的数据库工程师不仅关心自己运维的数据库系统的原理和发展，而且紧跟业界数据库前沿技术，并关注数据库领域的顶级会议。其中包括国际著名的数据库三大会议SIGMOD、VLDB、ICDE，还有知名数据库公司Percona主办的PerconaLive和Oracle主办的OpenWorld，以及国内知名的数据库工程师盛会中国数据库技术大会(DTCC)等。

从另外一个角度说，数据库工程师工作领域对实践经验和独立工作能力要求较高，没有经过大量的动手实践是很难胜任数据库工程师相关工作的。

正是由于上述原因，其职场现状是数据库工程师职位不易进入，而用人单位很难找到合适的从业人员，人员缺口非常大。

也正是由于上述原因，随着工作年限的增长，数据库工程师的经验在增加，就像医生一样，其价值会越来越高，可以逐步成长为资深数据库工程师、系统架构师、信息主管（CIO）等等，而不会出现许多软件开发从业人员在一定年龄后面临的转行问题。

另外，从职业前景看，从事数据库工程师有着更多的职场机遇。一般而言，系统中的软硬件都是IBM、HP、Oracle等业界一流厂商提供的，在与厂商谈判、合作、测试、实施、维护、优化等等过程中，会产生许多极佳的职场机遇，这一点是从事开发工作很难比拟的。

从数据库工程师的工资统计数据看，随着工作经验的积累，数据库工程师工资的增长幅度会远大于其它的计算机方向。

从工作的稳定性上看，系统的复杂性和经验的重要性已经决定了数据库工程师职位的不可替代性。

从知识的积累、更新和替代角度看，数据库的根基始终没变，变的是不断增强的功能和不断扩展的应用范围。因此，在不同时期所学的知识和获得的经验是叠加和累积的关系，而不像IT许多其他职业方向那样“唯一不变的是变化”，其知识是东风压倒西风还是西风压倒东风的关系。

因此，数据库工程师职业是一个高挑战和高回报的职业，有一定能力的和聪明的技术人员应该挑战自我，进入这个被二十多年事实不断证明的越来越有前景的职业。

在数据库中，函数依赖（Functional Dependency，FD）是一种约束条件，用于描述关系模式中属性之间的依赖关系。具体来说，如果关系模式R中属性集X的取值能够唯一确定属性集Y的取值，那么我们称X函数决定（determine）Y，表示为X Y，其中X称为决定因素（determinant），Y称为被决定因素（dependent）。函数依赖是数据库设计中的重要概念，它可以帮助我们分析和优化关系模式的结构，避免数据冗余和不一致性，提高数据库的性能和可维护性。

在函数依赖中，还有一些重要的名词需要解释：

1 超键（Supper Key）：指在关系模式R中，能够唯一标识元组的属性集称为超键。超键包括关系模式中的所有属性，也包括属性的组合。例如，如果在一个关系模式中，属性A和属性B的组合能够唯一标识元组，那么{A,B}就是一个超键。

2 候选键（Candidate Key）：指在关系模式R中，能够唯一标识元组的最小超键称为候选键。候选键是指具有最小决定因素的超键，也就是不能再去掉任何一个属性而保持唯一性的超键。例如，如果在一个关系模式中，属性A和属性B的组合能够唯一标识元组，并且不能再去掉任何一个属性而保持唯一性，那么{A,B}就是一个候选键。

3 主键（Primary Key）：指在关系模式R中，选定的用于唯一标识元组的候选键称为主键。主键是从候选键中选择的一个，用于唯一标识关系中的元组。一个关系模式只能有一个主键，而一个候选键可以是多个属性的组合。

以上就是关于数据库索引创建需考虑因素全部的内容，包括:数据库索引创建需考虑因素、7个因素决定大数据的复杂性 如何处理、简述数据库的三大范式和五大约束等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！