本文目录一览：
- 1、刚开始学mysql数据库,不明白其中的客户端和服务器,这里的服务器是要通过网络连接到达还是在安装了
- 2、求高手优化MySQL数据库，数据库反应太慢。
- 3、关于在mysql中建表的问题
- 4、《深入浅出MySQL数据库开发优化与管理维护第3版》pdf下载在线阅读全文，求百度网盘云资源
- 5、北大青鸟设计培训：Mysql数据库的设计和优化？
刚开始学mysql数据库,不明白其中的客户端和服务器,这里的服务器是要通过网络连接到达还是在安装了
1。首先说明一下服务器和客户端的分别，服务器是指安装mysql的那台机器，而客户端是远程通过网络使用服务器上的mysql，客户端通过得知远程服务器的ip地址以及mysql的一些密码信息等使用mysql数据库
2。说明一下数据库是一个什么样的存在，在你安装某种数据库的时候都会配置一些系统信息，然后设定某些和机器硬件，比如内存等连接的端口，这样通过这些端口，就可以把你先存储的信息存到存储空间去，而建立数据库就是通过某些代码（mysql）定义好的方式来建立某些存储数据的空间。这样每个数据库其实就是一个存储数据的存储空间。
3.建立表的原理，其实就是在你已经建立好的数据库库存储空间中，继续分配空间给每一个表，然后每一个表里再存储数据
4.而上面你说的打几句代码建表，其实就是通过代码，然后翻译成机器语言，让计算机分配出一些存储空间，然后通过某些形式编译成表的视图样式反应给你看，其实还是一个空间而已，这么说明白了吗？？
打了挺多，明白了得话给个采纳，谢了
求高手优化MySQL数据库，数据库反应太慢。
在开始演示之前，我们先介绍下两个概念。
概念一，数据的可选择性基数，也就是常说的cardinality值。
查询优化器在生成各种执行计划之前，得先从统计信息中取得相关数据，这样才能估算每步操作所涉及到的记录数，而这个相关数据就是cardinality。简单来说，就是每个值在每个字段中的唯一值分布状态。
比如表t1有100行记录，其中一列为f1。f1中唯一值的个数可以是100个，也可以是1个，当然也可以是1到100之间的任何一个数字。这里唯一值越的多少，就是这个列的可选择基数。
那看到这里我们就明白了，为什么要在基数高的字段上建立索引，而基数低的的字段建立索引反而没有全表扫描来的快。当然这个只是一方面，至于更深入的探讨就不在我这篇探讨的范围了。
概念二，关于HINT的使用。
这里我来说下HINT是什么，在什么时候用。
HINT简单来说就是在某些特定的场景下人工协助MySQL优化器的工作，使她生成最优的执行计划。一般来说，优化器的执行计划都是最优化的，不过在某些特定场景下，执行计划可能不是最优化。
比如：表t1经过大量的频繁更新操作，（UPDATE,DELETE,INSERT），cardinality已经很不准确了，这时候刚好执行了一条SQL，那么有可能这条SQL的执行计划就不是最优的。为什么说有可能呢？
来看下具体演示
譬如，以下两条SQL，
A：
select * from t1 where f1 = 20;
B：
select * from t1 where f1 = 30;
如果f1的值刚好频繁更新的值为30，并且没有达到MySQL自动更新cardinality值的临界值或者说用户设置了手动更新又或者用户减少了sample page等等，那么对这两条语句来说，可能不准确的就是B了。
这里顺带说下，MySQL提供了自动更新和手动更新表cardinality值的方法，因篇幅有限，需要的可以查阅手册。
那回到正题上，MySQL 8.0 带来了几个HINT，我今天就举个index_merge的例子。
示例表结构：
mysql desc t1;+------------+--------------+------+-----+---------+----------------+| Field | Type | Null | Key | Default | Extra |+------------+--------------+------+-----+---------+----------------+| id | int(11) | NO | PRI | NULL | auto_increment || rank1 | int(11) | YES | MUL | NULL | || rank2 | int(11) | YES | MUL | NULL | || log_time | datetime | YES | MUL | NULL | || prefix_uid | varchar(100) | YES | | NULL | || desc1 | text | YES | | NULL | || rank3 | int(11) | YES | MUL | NULL | |+------------+--------------+------+-----+---------+----------------+7 rows in set (0.00 sec)
表记录数：
mysql select count(*) from t1;+----------+| count(*) |+----------+| 32768 |+----------+1 row in set (0.01 sec)
这里我们两条经典的SQL：
SQL C：
select * from t1 where rank1 = 1 or rank2 = 2 or rank3 = 2;
SQL D：
select * from t1 where rank1 =100 and rank2 =100 and rank3 =100;
表t1实际上在rank1,rank2,rank3三列上分别有一个二级索引。
那我们来看SQL C的查询计划。
显然，没有用到任何索引，扫描的行数为32034，cost为3243.65。
mysql explain format=json select * from t1 where rank1 =1 or rank2 = 2 or rank3 = 2G*************************** 1. row ***************************EXPLAIN: { "query_block": { "select_id": 1, "cost_info": { "query_cost": "3243.65" }, "table": { "table_name": "t1", "access_type": "ALL", "possible_keys": [ "idx_rank1", "idx_rank2", "idx_rank3" ], "rows_examined_per_scan": 32034, "rows_produced_per_join": 115, "filtered": "0.36", "cost_info": { "read_cost": "3232.07", "eval_cost": "11.58", "prefix_cost": "3243.65", "data_read_per_join": "49K" }, "used_columns": [ "id", "rank1", "rank2", "log_time", "prefix_uid", "desc1", "rank3" ], "attached_condition": "((`ytt`.`t1`.`rank1` = 1) or (`ytt`.`t1`.`rank2` = 2) or (`ytt`.`t1`.`rank3` = 2))" } }}1 row in set, 1 warning (0.00 sec)
我们加上hint给相同的查询，再次看看查询计划。
这个时候用到了index_merge,union了三个列。扫描的行数为1103，cost为441.09，明显比之前的快了好几倍。
mysql explain format=json select /*+ index_merge(t1) */ * from t1 where rank1 =1 or rank2 = 2 or rank3 = 2G*************************** 1. row ***************************EXPLAIN: { "query_block": { "select_id": 1, "cost_info": { "query_cost": "441.09" }, "table": { "table_name": "t1", "access_type": "index_merge", "possible_keys": [ "idx_rank1", "idx_rank2", "idx_rank3" ], "key": "union(idx_rank1,idx_rank2,idx_rank3)", "key_length": "5,5,5", "rows_examined_per_scan": 1103, "rows_produced_per_join": 1103, "filtered": "100.00", "cost_info": { "read_cost": "330.79", "eval_cost": "110.30", "prefix_cost": "441.09", "data_read_per_join": "473K" }, "used_columns": [ "id", "rank1", "rank2", "log_time", "prefix_uid", "desc1", "rank3" ], "attached_condition": "((`ytt`.`t1`.`rank1` = 1) or (`ytt`.`t1`.`rank2` = 2) or (`ytt`.`t1`.`rank3` = 2))" } }}1 row in set, 1 warning (0.00 sec)
我们再看下SQL D的计划：
不加HINT，
mysql explain format=json select * from t1 where rank1 =100 and rank2 =100 and rank3 =100G*************************** 1. row ***************************EXPLAIN: { "query_block": { "select_id": 1, "cost_info": { "query_cost": "534.34" }, "table": { "table_name": "t1", "access_type": "ref", "possible_keys": [ "idx_rank1", "idx_rank2", "idx_rank3" ], "key": "idx_rank1", "used_key_parts": [ "rank1" ], "key_length": "5", "ref": [ "const" ], "rows_examined_per_scan": 555, "rows_produced_per_join": 0, "filtered": "0.07", "cost_info": { "read_cost": "478.84", "eval_cost": "0.04", "prefix_cost": "534.34", "data_read_per_join": "176" }, "used_columns": [ "id", "rank1", "rank2", "log_time", "prefix_uid", "desc1", "rank3" ], "attached_condition": "((`ytt`.`t1`.`rank3` = 100) and (`ytt`.`t1`.`rank2` = 100))" } }}1 row in set, 1 warning (0.00 sec)
加了HINT，
mysql explain format=json select /*+ index_merge(t1)*/ * from t1 where rank1 =100 and rank2 =100 and rank3 =100G*************************** 1. row ***************************EXPLAIN: { "query_block": { "select_id": 1, "cost_info": { "query_cost": "5.23" }, "table": { "table_name": "t1", "access_type": "index_merge", "possible_keys": [ "idx_rank1", "idx_rank2", "idx_rank3" ], "key": "intersect(idx_rank1,idx_rank2,idx_rank3)", "key_length": "5,5,5", "rows_examined_per_scan": 1, "rows_produced_per_join": 1, "filtered": "100.00", "cost_info": { "read_cost": "5.13", "eval_cost": "0.10", "prefix_cost": "5.23", "data_read_per_join": "440" }, "used_columns": [ "id", "rank1", "rank2", "log_time", "prefix_uid", "desc1", "rank3" ], "attached_condition": "((`ytt`.`t1`.`rank3` = 100) and (`ytt`.`t1`.`rank2` = 100) and (`ytt`.`t1`.`rank1` = 100))" } }}1 row in set, 1 warning (0.00 sec)
对比下以上两个，加了HINT的比不加HINT的cost小了100倍。
总结下，就是说表的cardinality值影响这张的查询计划，如果这个值没有正常更新的话，就需要手工加HINT了。相信MySQL未来的版本会带来更多的HINT。
关于在mysql中建表的问题
建议第一种方案.
第二种方案尽量避免.
(1)数据条数比较多对mysql来说,根本不是问题.我的项目中数据库纪录条数过亿.
(2)联合主键很好,检索到时会非常方便.你既然担心纪录条数多,那说明两表关系联动密切.以后的检索极有可能要按b表的ID来统计之类.
(3)不光是检索,维护使用A方案也非常方便.这方面我有教训.
当a与b的表关系发生变化的时候.update逗号分隔的数据就要求变得非常小心.
比如去掉1,2,3之间的那个2,你就得把整个字符串取出来,replace掉那个2,
如果数据多的话,replace动作就要非常非常小心.
(4)如果采用第二方案,展现的时候也需要额外的split动作.虽然这个动作不复杂.但每次split很是让人烦.
《深入浅出MySQL数据库开发优化与管理维护第3版》pdf下载在线阅读全文，求百度网盘云资源
《深入浅出MySQL数据库开发优化与管理维护第3版》百度网盘pdf最新全集下载:
链接：
?pwd=grx5 提取码：grx5
简介：《深入浅出MySQL：数据库开发、优化与管理维护（第3版）》源自网易公司多位资深数据库专家数年的经验总结和MySQL数据库的使用心得，在之前版本的基础之上，基于MySQL 5.7版本进行了内容升级，同时也对MySQL 8.0的重要功能进行了介绍。除了对原有内容的更新之外，本书还新增了作者在高可用架构、数据库自动化运维，以及数据库中间件方面的实践和积累。
《深入浅出MySQL：数据库开发、优化与管理维护（第3版）》分为“基础篇”“开发篇”“优化篇”“管理维护篇”和“架构篇”5个部分，共32章。基础篇面向MySQL的初学者，介绍了MySQL的安装与配置、SQL基础、MySQL支持的数据类型、MySQL中的运算符、常用函数等内容。开发篇面向的是MySQL设计和开发人员，内容涵盖了表类型（存储引擎）的选择、选择合适的数据类型、字符集、索引的设计和使用、开发常用数据库对象、事务控制和锁定语句、SQL中的安全问题、SQL Mode及相关问题、MySQL分区等。优化篇针对的是开发人员和数据库管理人员，内容包括SQL优化、锁问题、优化MySQL Server、磁盘I/O问题、应用优化、PS/SYS数据库、故障诊断等内容。管理维护篇适合数据库管理员阅读，介绍了MySQL高级安装和升级、MySQL中的常用工具、MySQL日志、备份与恢复、MySQL权限与安全、MySQL监控、MySQL常见问题和应用技巧、自动化运维系统的开发等内容。架构篇主要面向高级数据库管理人员和数据库架构设计师，内容包括MySQL复制、高可用架构、MySQL中间件等内容。
北大青鸟设计培训：Mysql数据库的设计和优化？
在JAVA开发中数据库的学习也是我们需要了解的，截下来几篇文章都是关于数据库的设计和应用，那么java课程培训机构废话不多说开始学习吧！ 数据库的设计 数据库设计是基础，数据库优化是建立在设计基础之上的。
好的数据库一定拥有好的设计。
数据库设计的目标是为用户和各种应用系统提供一个信息基础设施和高效的运行环境。
数据库的三大范式 第一范式1NF:所有的域都应该是原子性的，即数据库表的每一列都是不可分割的原子数据项，而不能是集合，数组，记录等非原子数据项。
第二范式2Nf:第二范式在第一范式的基础之上更进一层。
第二范式需要确保数据库表中的每一列都和主键相关，而不能只与主键的某一部分相关(主要针对联合主键而言)。
也就是说在一个数据库表中，一个表中只能保存一种数据，不可以把多种数据保存在同一张数据库表中。
第三范式3Nf:所有字段必须与主键直接相关，而不是间接相关。
也可以理解为字段不要和其他非主键字段相关. 注意:这三个范式尽可能去遵守,不是一定要墨守成规.这只是让我们设计的表的时候,越靠近这些范式,可以使字段尽量的减小冗余.但是有时候也可以根据实际需要小小的违背一下.但是第三范式违反一下还可以接受,但是第一范式别违反. 数据库设计的步骤 需求分析阶段 准确了解与分析用户需求(包括数据与处理)。
是整个设计过程的基础，是最困难、最耗费时间的一步。
概念结构设计阶段 是整个数据库设计的关键--设计数据库的E-R模型图，确认需求信息的正确和完整 Entity_Relationship---实体之间的关系 一对一 一对多 多对一