mysql数据库知识点总结，sql数据库基础知识
大家好，今天来为大家分享mysql数据库知识点总结的一些知识点，和sql数据库基础知识的问题解析，大家要是都明白，那么可以忽略，如果不太清楚的话可以看看本篇文章，相信很大概率可以解决您的问题，接下来我们就一起来看看吧！
MySQL知识点总结
只要字段值还可以继续拆分，就不满足第一范式。
范式设计得越详细，对某些实际操作可能会更好，但并非都有好处，需要对项目的实际情况进行设定。
在满足第一范式的前提下，其他列都必须完全依赖于主键列。如果出现不完全依赖，只可能发生在联合主键的情况下：
实际上，在这张订单表中，product_name只依赖于 product_id，customer_name只依赖于 customer_id。也就是说，product_name和 customer_id是没用关系的，customer_name和 product_id也是没有关系的。
这就不满足第二范式：其他列都必须完全依赖于主键列！
拆分之后，myorder表中的 product_id和 customer_id完全依赖于 order_id主键，而 product和 customer表中的其他字段又完全依赖于主键。满足了第二范式的设计！
在满足第二范式的前提下，除了主键列之外，其他列之间不能有传递依赖关系。
表中的 customer_phone有可能依赖于 order_id、 customer_id两列，也就不满足了第三范式的设计：其他列之间不能有传递依赖关系。
修改后就不存在其他列之间的传递依赖关系，其他列都只依赖于主键列，满足了第三范式的设计！
查询每门课的平均成绩。
查询 score表中至少有 2名学生选修，并以 3开头的课程的平均分数。
分析表发现，至少有 2名学生选修的课程是 3-105、3-245、6-166，以 3开头的课程是 3-105、3-245。也就是说，我们要查询所有 3-105和 3-245的 degree平均分。
查询所有学生的 name，以及该学生在 score表中对应的 c_no和 degree。
通过分析可以发现，只要把 score表中的 s_no字段值替换成 student表中对应的 name字段值就可以了，如何做呢？
查询所有学生的 no、课程名称( course表中的 name)和成绩( score表中的 degree)列。
只有 score关联学生的 no，因此只要查询 score表，就能找出所有和学生相关的 no和 degree：
然后查询 course表：
只要把 score表中的 c_no替换成 course表中对应的 name字段值就可以了。
查询所有学生的 name、课程名( course表中的 name)和 degree。
只有 score表中关联学生的学号和课堂号，我们只要围绕着 score这张表查询就好了。
只要把 s_no和 c_no替换成 student和 srouse表中对应的 name字段值就好了。
首先把 s_no替换成 student表中的 name字段：
再把 c_no替换成 course表中的 name字段：
查询 95031班学生每门课程的平均成绩。
在 score表中根据 student表的学生编号筛选出学生的课堂号和成绩：
这时只要将 c_no分组一下就能得出 95031班学生每门课的平均成绩：
查询在 3-105课程中，所有成绩高于 109号同学的记录。
首先筛选出课堂号为 3-105，在找出所有成绩高于 109号同学的的行。
查询所有成绩高于 109号同学的 3-105课程成绩记录。
查询所有和 101、108号学生同年出生的 no、name、birthday列。
查询'张旭'教师任课的学生成绩表。
首先找到教师编号：
通过 sourse表找到该教师课程号：
通过筛选出的课程号查询成绩表：
查询某选修课程多于5个同学的教师姓名。
首先在 teacher表中，根据 no字段来判断该教师的同一门课程是否有至少5名学员选修：
查看和教师编号有有关的表的信息：
我们已经找到和教师编号有关的字段就在 course表中，但是还无法知道哪门课程至少有5名学生选修，所以还需要根据 score表来查询：
根据筛选出来的课程号，找出在某课程中，拥有至少5名学员的教师编号：
在 teacher表中，根据筛选出来的教师编号找到教师姓名：
查询“计算机系”课程的成绩表。
思路是，先找出 course表中所有计算机系课程的编号，然后根据这个编号查询 score表。
查询计算机系与电子工程系中的不同职称的教师。
查询课程 3-105且成绩至少高于 3-245的 score表。
查询课程 3-105且成绩高于 3-245的 score表。
查询某课程成绩比该课程平均成绩低的 score表。
查询所有任课(在 course表里有课程)教师的 name和 department。
查询 student表中至少有 2名男生的 class。
查询 student表中不姓"王"的同学记录。
查询 student表中每个学生的姓名和年龄。
查询 student表中最大和最小的 birthday值。
以 class和 birthday从大到小的顺序查询 student表。
查询"男"教师及其所上的课程。
查询最高分同学的 score表。
查询和"李军"同性别的所有同学 name。
查询和"李军"同性别且同班的同学 name。
查询所有选修"计算机导论"课程的"男"同学成绩表。
需要的"计算机导论"和性别为"男"的编号可以在 course和 student表中找到。
建立一个 grade表代表学生的成绩等级，并插入数据：
查询所有学生的 s_no、c_no和 grade列。
思路是，使用区间( BETWEEN)查询，判断学生的成绩( degree)在 grade表的 low和 upp之间。
准备用于测试连接查询的数据：
分析两张表发现，person表并没有为 cardId字段设置一个在 card表中对应的 id外键。如果设置了的话，person中 cardId字段值为 6的行就插不进去，因为该 cardId值在 card表中并没有。
要查询这两张表中有关系的数据，可以使用 INNER JOIN(内连接)将它们连接在一起。
完整显示左边的表( person)，右边的表如果符合条件就显示，不符合则补 NULL。
完整显示右边的表( card)，左边的表如果符合条件就显示，不符合则补 NULL。
完整显示两张表的全部数据。
在 MySQL中，事务其实是一个最小的不可分割的工作单元。事务能够保证一个业务的完整性。
比如我们的银行转账：
在实际项目中，假设只有一条 SQL语句执行成功，而另外一条执行失败了，就会出现数据前后不一致。
因此，在执行多条有关联 SQL语句时，事务可能会要求这些 SQL语句要么同时执行成功，要么就都执行失败。
在 MySQL中，事务的自动提交状态默认是开启的。
自动提交的作用：当我们执行一条 SQL语句的时候，其产生的效果就会立即体现出来，且不能回滚。
什么是回滚？举个例子：
可以看到，在执行插入语句后数据立刻生效，原因是 MySQL中的事务自动将它提交到了数据库中。那么所谓回滚的意思就是，撤销执行过的所有 SQL语句，使其回滚到最后一次提交数据时的状态。
在 MySQL中使用 ROLLBACK执行回滚：
由于所有执行过的 SQL语句都已经被提交过了，所以数据并没有发生回滚。那如何让数据可以发生回滚？
将自动提交关闭后，测试数据回滚：
那如何将虚拟的数据真正提交到数据库中？使用 COMMIT:
事务的实际应用，让我们再回到银行转账项目：
这时假设在转账时发生了意外，就可以使用 ROLLBACK回滚到最后一次提交的状态：
这时我们又回到了发生意外之前的状态，也就是说，事务给我们提供了一个可以反悔的机会。假设数据没有发生意外，这时可以手动将数据真正提交到数据表中：COMMIT。
事务的默认提交被开启(@@AUTOCOMMIT= 1)后，此时就不能使用事务回滚了。但是我们还可以手动开启一个事务处理事件，使其可以发生回滚：
仍然使用 COMMIT提交数据，提交后无法再发生本次事务的回滚。
事务的四大特征：
事务的隔离性可分为四种(性能从低到高)：
查看当前数据库的默认隔离级别：
修改隔离级别：
测试 READ UNCOMMITTED(读取未提交)的隔离性：
由于小明的转账是在新开启的事务上进行操作的，而该操作的结果是可以被其他事务（另一方的淘宝店）看见的，因此淘宝店的查询结果是正确的，淘宝店确认到账。但就在这时，如果小明在它所处的事务上又执行了 ROLLBACK命令，会发生什么？
这就是所谓的脏读，一个事务读取到另外一个事务还未提交的数据。这在实际开发中是不允许出现的。
把隔离级别设置为 READ COMMITTED：
这样，再有新的事务连接进来时，它们就只能查询到已经提交过的事务数据了。但是对于当前事务来说，它们看到的还是未提交的数据，例如：
但是这样还有问题，那就是假设一个事务在操作数据时，其他事务干扰了这个事务的数据。例如：
虽然 READ COMMITTED让我们只能读取到其他事务已经提交的数据，但还是会出现问题，就是在读取同一个表的数据时，可能会发生前后不一致的情况。*这被称为*不可重复读现象( READ COMMITTED)。
将隔离级别设置为 REPEATABLE READ(可被重复读取):
测试 REPEATABLE READ，假设在两个不同的连接上分别执行 START TRANSACTION:
当前事务开启后，没提交之前，查询不到，提交后可以被查询到。但是，在提交之前其他事务被开启了，那么在这条事务线上，就不会查询到当前有操作事务的连接。相当于开辟出一条单独的线程。
无论小张是否执行过 COMMIT，在小王这边，都不会查询到小张的事务记录，而是只会查询到自己所处事务的记录：
这是因为小王在此之前开启了一个新的事务( START TRANSACTION)*，那么*在他的这条新事务的线上，跟其他事务是没有联系的，也就是说，此时如果其他事务正在操作数据，它是不知道的。
然而事实是，在真实的数据表中，小张已经插入了一条数据。但是小王此时并不知道，也插入了同一条数据，会发生什么呢？
报错了，操作被告知已存在主键为 6的字段。这种现象也被称为幻读，一个事务提交的数据，不能被其他事务读取到。
顾名思义，就是所有事务的写入操作全都是串行化的。什么意思？把隔离级别修改成 SERIALIZABLE:
还是拿小张和小王来举例：
此时会发生什么呢？由于现在的隔离级别是 SERIALIZABLE(串行化)，串行化的意思就是：假设把所有的事务都放在一个串行的队列中，那么所有的事务都会按照固定顺序执行，执行完一个事务后再继续执行下一个事务的写入操作(这意味着队列中同时只能执行一个事务的写入操作)。
根据这个解释，小王在插入数据时，会出现等待状态，直到小张执行 COMMIT结束它所处的事务，或者出现等待超时。
转载：
MySQL数据库实训报告 实训心得
MySQL数据库实训心得
本学期的MySQL数据库实训围绕设计一套通用的单商户销售平台数据库展开，通过实践操作，我不仅掌握了数据库设计的核心流程，还深化了对MySQL语法和实际应用的理解。以下从实训内容、技能提升、问题解决和总结感悟四个方面展开心得分享。
一、实训内容与流程本次实训的核心任务是构建一个支持单商户销售业务的数据库系统，功能模块划分为七大板块：
商品模块：存储商品基本信息（名称、价格、分类等）。订单模块：记录订单详情（用户ID、商品ID、数量、时间等）。库存模块：管理商品库存数量及变动记录。日志模块：记录系统操作日志（如用户登录、数据修改等）。积分模块：跟踪用户积分获取与消耗情况。评价模块：存储用户对商品的评分和评论。用户模块：管理用户账号信息（用户名、密码、联系方式等）。具体流程：
需求分析：通过思维导图明确各模块的数据表结构及关联关系。数据库创建：使用CREATE DATABASE语句新建数据库，并设置字符集（如utf8mb4）以支持多语言。建表与数据插入：根据模块设计七张表，定义主键、外键约束，并通过INSERT语句填充测试数据。功能实现：通过SQL查询实现业务逻辑，例如：使用SELECT语句检索商品信息；
通过GROUP BY子句统计用户消费金额；
利用子查询筛选高评分商品；
结合UPDATE和DELETE管理库存和订单状态。
工具应用：使用PyCharm连接MySQL，通过Python代码（如pymysql库）实现数据检索与验证。二、技能提升与收获SQL语法灵活运用：
掌握了SELECT语句的核心语法，包括条件筛选（WHERE）、排序（ORDER BY）和分页（LIMIT）。
理解了GROUP BY与聚合函数（如SUM、COUNT）的结合使用，例如统计各分类商品销量。
学会了子查询的嵌套写法，例如通过子查询筛选“购买过某商品的用户”。
数据库管理能力增强：
熟练执行表的增删改操作（CREATE TABLE、ALTER TABLE、DROP TABLE）。
理解了外键约束对数据完整性的保障作用，例如订单表中的用户ID必须关联用户表的主键。
跨工具协作经验：
通过PyCharm连接MySQL，实现了从前端到后端的数据交互验证，加深了对数据库在实际开发中角色的理解。
三、问题与解决方法知识点遗忘：
问题：在编写复杂查询时，对JOIN操作的语法记忆模糊。
解决：回顾教学视频中关于多表查询的章节，并参考MySQL官方文档巩固语法。
逻辑错误排查：
问题：子查询结果不符合预期，导致主查询数据缺失。
解决：通过逐步拆解子查询，在PyCharm中分段执行并打印中间结果，定位逻辑漏洞。
性能优化尝试：
问题：对大规模数据表进行GROUP BY统计时响应缓慢。
解决：与同学讨论后，学习到通过添加索引（CREATE INDEX）加速查询，并优化SQL写法（如避免SELECT*）。
四、总结与感悟理论与实践结合的重要性：通过实训，我认识到课堂上学到的SQL语法需结合具体业务场景才能发挥价值。例如，日志模块的设计让我理解了事务（TRANSACTION）在保证数据一致性中的作用。
自主学习与协作的平衡：
遇到问题时，优先通过官方文档和权威教程自主解决，培养了独立解决问题的能力。
与同学讨论不仅加速了问题解决，还拓展了思路（如学习到不同的索引优化策略）。
对未来学习的启示：MySQL作为关系型数据库的代表，其设计思想（如范式理论）和操作逻辑是学习其他数据库（如PostgreSQL）的基础。
计划进一步学习数据库性能调优、存储过程编写等高级内容，为开发复杂系统（如电商后台）打下基础。
本次实训让我从“理论认知”迈向“实践应用”，不仅掌握了MySQL的核心技能，更体会到数据库在信息系统中的核心地位。感谢老师的悉心指导，未来我将继续深化学习，提升数据建模与优化能力。
MySql 三大知识点——索引、锁、事务
MySQL的三大核心知识点——索引、锁、事务，是数据库性能优化和并发控制的关键，以下是详细解析：
一、索引定义：索引是数据库的“目录”，通过快速定位数据提升查询效率，类似书籍目录通过页码查找内容。
优点：
天生排序：数据按索引字段有序存储。
快速查找：通过B+树结构减少磁盘IO次数。
缺点：
占用空间：索引数据需额外存储。
降低写入速度：数据更新时需同步维护索引。
适用场景：
小表（全表扫描更快）、中大表（推荐使用）、超级大表（索引效果有限）。
索引类型：
实现方式：
聚集索引：数据按索引顺序物理存储（InnoDB主键默认聚集）。
辅助索引：非聚集索引，存储主键值而非数据本身。
功能分类：
普通索引：无约束，基础索引类型。
唯一索引：确保字段值唯一，允许空值（仅一个）。
主键索引：特殊的唯一索引，不允许空值。
复合索引：多列组合索引，遵循最左前缀原则。
外键索引：InnoDB特有，维护表间数据一致性。
全文索引：仅支持InnoDB/MyISAM，对英文文本分词检索（生产环境常用ES/Solr替代）。
B+树结构：
非叶子节点：仅存储索引和指针，不存数据，提高单节点索引容量。
叶子节点：存储数据和指向相邻节点的指针，形成链表结构。
性能优势：
3层B+树可存储约10亿索引，查询仅需2-3次磁盘IO。
支持范围查询和排序操作。
设计建议：
主键尽量短（如自增INT），避免UUID导致页分裂。
分库分表时，可保留自增主键，逻辑主键作为唯一索引。
B树：非叶子节点存储数据，索引容量受限
B+树：非叶子节点仅存索引，叶子节点存储数据并链表连接二、锁机制核心目标：保证并发事务下的数据一致性，通过锁的粒度和类型控制访问冲突。
锁类型：
按操作分：
共享锁（S锁）：读锁，允许多事务并发读取。
排他锁（X锁）：写锁，独占资源，禁止其他事务读写。
意向锁：表级锁，标记行锁存在，避免全表扫描检查。
按策略分：
悲观锁：通过SELECT... FOR UPDATE显式加锁。
乐观锁：通过版本号（如version字段）实现CAS机制。
锁粒度：
表锁：锁定整张表，并发度低（如MyISAM引擎）。
页锁：锁定数据页，中间粒度（BerkeleyDB引擎）。
行锁：锁定单行，高并发（InnoDB引擎）。
锁算法：
Record Lock：锁定单行记录。
Gap Lock：锁定索引间隙，防止幻读。
Next-Key Lock：Record Lock+ Gap Lock，锁定记录及间隙（InnoDB默认RR隔离级别使用）。
特殊场景：
默认读操作：使用MVCC（多版本并发控制）实现一致性非锁定读，不上锁。
手动加锁：SELECT... FOR UPDATE（X锁）或LOCK IN SHARE MODE（S锁）实现一致性锁定读。
SERIALIZABLE级别：通过串行化执行避免丢失更新（如转账场景）。
行锁失效场景：
查询未命中索引时，优化器可能降级为表锁。
SERIALIZABLE级别防止丢失更新三、事务ACID特性：
原子性（Atomicity）：通过Undo Log回滚未提交变更。
一致性（Consistency）：由原子性、隔离性、持久性共同保证。
隔离性（Isolation）：通过MVCC和锁实现，解决脏读、不可重复读、幻读。
持久性（Durability）：通过Redo Log保证事务提交后数据不丢失。
隔离级别：
未提交读（RU）：允许脏读（事务未提交的修改可见）。
已提交读（RC）：避免脏读，但允许不可重复读（每次读生成新Read View）。
可重复读（RR）：避免脏读和不可重复读（事务内使用同一Read View），MySQL通过MVCC和Next-Key Lock避免幻读。
串行化（SERIALIZABLE）：完全串行执行，避免所有并发问题（性能最低）。
MVCC实现：
隐藏字段：每行记录包含事务ID、回滚指针、删除标记等。
Read View：事务启动时生成，决定可见数据版本。
Undo Log：存储数据历史版本，形成版本链。
隔离级别与并发问题关系总结索引：优先使用短主键和复合索引，避免超级大表索引失效。锁：根据业务选择合适粒度，高并发场景慎用表锁。事务：合理设置隔离级别，RR级别通常能满足需求，SERIALIZABLE仅用于极端场景。通过理解这三大核心机制，可有效优化MySQL性能并避免并发问题。
好了，关于mysql数据库知识点总结和sql数据库基础知识的问题到这里结束啦，希望可以解决您的问题哈！