数据库主键

目录 1. DQL:查询语句 1. 排序查询 2. 聚合函数 3. 分组查询 4. 分页查询 2. 约束 3. 多表之间的关系 4. 范式 5. 数据库的备份和还原 DQL:查询语句 1. 排序查询 语法：order by 子句 order by 排序字段1 排序方式1 ， 排序字段2 排序方式2... 排序方式： ASC：升序，默认的。 DESC：降序。 注意：如果有多个排序条件，则当前边的条件值一样时，才会判断第二条件。 2. 聚合函数：将一列数据作为一个整体，进行纵向的计算。 1. count：计算个数 ####1. 一般选择非空的列：主键 ####2. count(*) 2. max：计算最大值 3. min：计算最小值 4. sum：计算和 5. avg：计算平均值 注意：聚合函数的计算，排除null值。 解决方案： 选择不包含非空的列进行计算 IFNULL函数 3. 分组查询: 语法：group by 分组字段； 注意： 分组之后查询的字段：分组字段、聚合函数 where 和 having 的区别？ where 在分组之前进行限定，如果不满足条件，则不参与分组。having在分组之后进行限定，如果不满足结果，则不会被查询出来 where 后不可以跟聚合函数，having可以进行聚合函数的判断。 -- 按照性别分组。分别查询男、女同学的平均分 SELECT sex ,

目录 聚合查询 聚合函数 分组查询 F与Q查询 F能够获取表中字段所对应的值 Q查询 Q对象高级用法 orm 字段及参数 自定义字段 orm中的事务操作 1.第一范式: 2.第二范式: 3.第三范式 django中创建事务 聚合查询 ​ 级联删除 级联更新 (外键字段带来的约束) ​ 操作外键字段管理数据时 ​ 书和出版社是一对多的关系 外键字段在书那 ​ 这个时候把出版社删了 所对应的书字段也会自动给删除 ​ 这个时候如果你把出版社主键改变了 那么书籍表中对应的出版社主键值也会改变 聚合函数 ​ 聚合函数必须用在分组之后 ​ 没有分组其实默认就是一组 关键字 aggregate 还需要导入模块 from django.db.models import Max,Min,Sum,Avg,Count res = models.Book.objects.aggregate(sm = Sum('price')) res = models.Book.objects.aggregate(Max('price'),Min('prince'),Sum('price'),Count('price'),Avg('price')) 分组查询 ​ mysql 中用 group by ​ 什么时候用分组 ​ 1.统计每一个部门的平均薪资 ​ 2.统计每一个部门的男女比例 ​ 1.关键字 annotate ​

出处： 数据库分库分表思路 一. 数据切分 　　关系型数据库本身比较容易成为系统瓶颈，单机存储容量、连接数、处理能力都有限。当单表的数据量达到1000W或100G以后，由于查询维度较多，即使添加从库、优化索引，做很多操作时性能仍下降严重。此时就要考虑对其进行切分了，切分的目的就在于减少数据库的负担，缩短查询时间。 　　数据库分布式核心内容无非就是数据切分（Sharding） ，以及切分后对数据的定位、整合。数据切分就是将数据分散存储到多个数据库中，使得单一数据库中的数据量变小，通过扩充主机的数量缓解单一数据库的性能问题，从而达到提升数据库操作性能的目的。 　　数据切分根据其切分类型，可以分为两种方式：垂直（纵向）切分和水平（横向）切分 1、垂直（纵向）切分 　　垂直切分常见有垂直分库和垂直分表两种。 　　垂直分库 就是根据业务耦合性，将关联度低的不同表存储在不同的数据库。做法与大系统拆分为多个小系统类似，按业务分类进行独立划分。与"微服务治理"的做法相似，每个微服务使用单独的一个数据库。如图： 　　 垂直分表 是基于数据库中的"列"进行，某个表字段较多，可以新建一张扩展表，将不经常用或字段长度较大的字段拆分出去到扩展表中。在字段很多的情况下（例如一个大表有100多个字段），通过"大表拆小表"，更便于开发与维护，也能避免跨页问题，MySQL底层是通过数据页存储的

主键自增长： 主键只能够设置在数据类型为整型的列上。可以子集设置主键值，也可以利用主键自增长的特性 实现主键数据的自动更新。自增长只能作用于当前的数据库，但是在集群的状态下主键自增长可能 会失效。 使用uuid来代替主键自增长，这样可以避免在集群环境的主键重复。 使用代理主键来代替自然主键，防止业务变更时导致系统崩溃。 非空约束： 将某些列的值设置为非空(not null),虽然约束为非空，但是可以重复。 唯一约束： 将某些列的值设置为唯一(unique)，该约束为唯一约束，但是并没有规定值不可以为空。 概念模型： 实体之间的关系： 一对一：老公和夫妻之间的关系。 一对多：老师可以有多个学生。 多对多：学生和老师之间的关系，老师可有多个学生，学生也可以有多个老师。 外键约束： 外键必须是另一张表的主键。（外键必须引用主键） 外键是可用重复的，但必须是另一张表的主键 外键也是可以为空的 一张表中可以含有多个外键，可引用多个表的主键。 创建具有外键的表时，包含该外键需要引用的主表需要先存在，并且在删除表时，要先删除从表 才能够删除主表。 外键约束的创建方法： 1 首先可以在创建一张表的时候创建表中外键列，语法为constraint 约束名 foreign key(列名）references 主键表(主键列名）。创建外键列时不必和主键的列同名。 2 可以使用alter table 表明

ORM === 校验: 1.ORM内部为强制校验 2.ORM外部校验 (保存,更新,插入时校验) 过滤: 校验不在包含过滤功能 参数及方法变更: 1.find不在带参数 2.save拆分为create跟update,并增加校验类参数,规则为覆盖叠加 3.factory为ORM重写,可传两参数,用MODEL只有一个参数 4.find等查找不可用于已有实体的ORM 5.校验过滤规则的转变 6.unique指定字段的唯一判断函数 融合数据库操作: 数据库的CURD操作增加方法,方便使用. 方法及说明: A:ORM自动维护 字段缓存 $_column_cache 初始化缓存配置 $_init_cache 必要校验模型 $_validation 当前操作实体 $_object 是否有更改 $_changed 原数据(从数据库获取,并未更改的数据) $_original_values 自动加载的关系ORM $_related 是否通过内置必要校验 $_valid 是否加载实体成功 $_loaded 是否保存成功 $_saved 排序用存放字段 $_sorting 当前对象名 $_object_name 复写辅助对象 $_object_plural 表字段 $_table_columns 当前KEY中的值 $_primary_key_value 以下为映射到数据库操作相关属性: $_db

目录 数据库设计 三范式 第一范式（1NF）： 第二范式（2NF）： 第三范式（3NF）： E-R模型 数据库设计 关系型数据库建议在E-R模型的基础上，我们需要根据产品经理的设计策划，抽取出来模型与关系，制定出表结构，这是项目开始的第一步。 在开发中有很多设计数据库的软件，常用的如power designer，db designer等，这些软件可以直观的看到实体及实体间的关系。 设计数据库，可能是由专门的数据库设计人员完成，也可能是由开发组成员完成，一般是项目经理领组员完成。 三范式 经过研究和对使用中问题的总结，对于设计数据库提出了一些规范，这些规范被称为范式（Normal Form） 目前有迹可循的共有8种范式，一般需要遵循3范式即可： 第一范式（1NF）： 第一范式是最基本的范式，强调的是列的原子性，即列不能再分成其他几列 上图不符合第一范式，买家地址可以拆分 这样修改就遵循了第一范式。修改后的订单表 在用户使用城市进行分类的时候会非常方便，提高了数据库性能 第二范式（2NF）： 首先是基于第一范式，另外包含两部分内容，一是表必须有一个主键；二是没有包含在主键中的列必须完全依赖于主键，而不能只依赖主键的一部分。 也就是说在一个数据表中，只能保存一种数据，不能把多种数据保存在同一张表中。 上面的订单表可以继续拆分 第三范式（3NF）： 首先是基于第二范式

主键 如果一个属性或者一组属性能唯一标识一行数据，那么这个属性(组)就是主键； 数据表必须有主键，且只能有一个主键，且主键不能重复； 如果是一个属性作为主键，代表列的完整性约束； 如果是一组属性作为主键，代表表的完整性约束； 原则 1. 有且只有一个 2. 唯一性原则：不能重复 3. 最小化原则：如果一组属性作为主键，从这组属性中删除一个属性，仍然能唯一标识一行数据，那么这组属性就不是主键 外键 外键用于与另一张表关联； 它能唯一确定另一张表的记录，它是另一张表的主键； 外键可有可无，且可以有多个，且外键可以重复； 索引 索引是对表中一个或多个列进行排序的结构； 他可以加快查询速度； 索引又分为唯一索引、主键索引、聚集索引、非聚集索引； 唯一索引不能重复，主键索引就是主键，也不能重复； 非聚集索引可以重复； 非聚集索引是我们最常用的索引； 视图 数据库视图是个虚拟表或者罗技表，并非物理表，他是把一个或者多个表的部分数据进行处理后，生成的一张虚拟表； 它是动态表，当物理表的数据发生变化时，它也会变化； 一个 sql 语句理解视图 CREATE VIEW current_employees AS SELECT NAME, ID, SALARY FROM EMPLOYEES; # current_employees 视图表 # EMPLOYEES 原表 # 原表变，视图表也变

count(*)包括了所有的列，相当于行数，在统计结果的时候，不会忽略列值为NULL count(1)包括了所有列，用1代表代码行，在统计结果的时候，不会忽略列值为NULL count(列名)只包括列名那一列，在统计结果的时候，会忽略列值为空（这里的空不是只空字符串或者0，而是表示null）的计数，即某个字段值为NULL时，不统计 执行效率上： 列名为主键，count(列名)会比count(1)快 列名不为主键，count(1)会比count(列名)快 如果表多个列并且没有主键，则 count（1） 的执行效率优于 count（*） 如果有主键，则 select count（主键）的执行效率是最优的 如果表只有一个字段，则 select count（*）最优 当表的数据量大些时，对表作分析之后，使用count(1)还要比使用count(*)用时多了！ 执行计划上: count(1)和count(*)的效果是一样的。 但是在表做过分析之后，count(1)会比count(*)的用时少些（1w以内数据量），不过差不了多少。 如果count(1)是聚索引,id,那肯定是count(1)快。但是差的很小的。 因为count(*),自动会优化指定到那一个字段。所以没必要去count(1)，用count(*),sql会帮你完成优化的 因此：count(1)和count(*)基本上是没有差别！

前言 使用Mybatis的开发者，大多数都会遇到一个问题，就是要写大量的SQL在xml文件中， 除了特殊的业务逻辑SQL之外，还有大量结构类似的增删改查SQL 。而且，当数据库表结构改动时，对应的所有SQL以及实体类都需要更改。这工作量和效率的影响或许就是区别增删改查程序员和真正程序员的屏障。这时，通用Mapper便应运而生…… 什么是通用Mapper 通用Mapper就是 为了解决单表增删改查 ，基于Mybatis的插件。开发人员不需要编写SQL， 不需要在DAO中增加方法，只要写好实体类，就能支持相应的增删改查方法 。 如何使用 以MySQL为例，假设存在这样一张表： CREATE TABLE `test_table` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `name` varchar(255) DEFAULT '', `create_time` datetime DEFAULT NULL, `create_user_id` varchar(32) DEFAULT NULL, `update_time` datetime DEFAULT NULL, `update_user_id` varchar(32) DEFAULT NULL, `is_delete` int(8) DEFAULT NULL, PRIMARY KEY (`id

设置索引 存为sql,仅结构 先看有没有player删除，反引号是为了与保留字区分 player_name 字符utf8 ,排序规则utf_general_ci，大小写不敏感,敏感的为utf8_bin,采用unique,也可以设置为normal，索引方式可以设置为btree或者hash 引擎为InnoDB 字符集 排序 ROW_FORMAT行格式为Dynamic 常见约束 主键 外键 唯一性 NOT NULL DEFAULT CHECK 设计原则 更少的表，更少的字段，更少的联合主键，多增加主键与外键增强表之间的复用率，可重用 如果正确性>性能，建议使用外键 如果不用外键，有一定的风险，业务层实现，必须同时修改，业务层与数据层有一定的耦合，工作中业务可能经常发生变化 结论 早期用外键，后期用业务，分析28理论， 会有20%的外键造成80%的资源效率 2的部分用业务实现，减少死锁出现概率，提高并发处理能力 来源： https://www.cnblogs.com/autointerface/p/11934247.html