1.视图：
什么是视图：
在关系型数据库中，视图（View）是一种虚拟表，它是基于一个或多个表的查询结果构建的。视图并不存储实际的数据，而是根据查询定义的规则从底层表中提取数据动态生成的。
视图可以看作是逻辑上存在的表，它能够提供一种对数据库中数据的不同逻辑表现方式，以满足不同用户或应用程序的需求。视图可以隐藏底层表的复杂性，提供简单明了的数据访问界面，同时还可以限制用户对数据的访问权限。
创建视图的过程是通过在数据库中定义一个查询语句，并使用CREATE VIEW语句来给这个查询结果命名，从而创建了一个虚拟表。
视图在数据库中扮演了重要的角色，它能够简化数据查询、提高数据访问的灵活性和安全性，并且能够将复杂的查询逻辑封装起来，方便使用和维护。
比如，假设有一个名为"employees"的表，包含员工的详细信息，包括姓名、工号、职位等等。可以通过以下方式创建一个视图来展示只包含特定职位的员工：
CREATE VIEW view_employees AS SELECT name, employee_id, position FROM employees WHERE position = 'Manager';
视图创建完成后，就可以像操作普通表一样使用它进行数据查询，例如：
SELECT * FROM view_employees;
视图与数据表的区别：
视图（View）和数据表是关系型数据库中的两个重要概念，它们在以下几个方面有一些区别：
- 存储方式：数据表是实际存储数据的物理表格，数据以行和列的形式存储在表中，具有物理存储空间。而视图是一个虚拟的表，不存储实际的数据，它是根据查询定义的规则从基础表中动态生成的。
- 数据内容：数据表中存储了实际数据记录，可以直接对表中的数据进行增删改查操作。而视图是根据查询定义的结果集，只能用于查询，不能直接进行数据修改。对视图的修改操作会反映到基础表中，而不是直接修改视图本身。
- 数据访问和安全性：视图可以提供对底层表的不同逻辑访问方式，可以隐藏复杂的查询逻辑，简化用户的查询操作，提供安全的数据访问界面。通过视图可以对底层表的列进行过滤、重命名、连接等操作，实现数据的定制化访问。数据表没有这种灵活的访问能力，直接操作表格中的原始数据。
- 维护和性能：视图的查询定义是基于底层表的查询语句，当底层表的数据发生改变时，视图的数据也会相应地改变。这意味着视图不需要独立维护，与底层表保持一致。而对数据表的修改需要通过更改表结构或执行相应的数据操作语句来进行，需要额外的维护工作。另外，对视图的查询可能涉及到底层表的联接等复杂操作，性能方面可能会有一定的影响。
总的来说，数据表是实际存储数据的物理结构，数据内容可直接操作，而视图是基于查询定义的虚拟表，提供了对底层表的定制化访问方式，提供灵活性和安全性，但不能直接修改数据。在实际使用中，根据需求和设计，可以灵活地选择使用数据表和视图。
优点：
视图（View）在关系型数据库中有以下几个优点：
- 简化数据访问：视图可以提供简单、清晰的数据访问界面，将复杂的查询逻辑封装起来，使用户能够以更直观、易读的方式获取所需数据，无需了解底层表的结构和关系。
- 数据安全性：通过视图，可以限制用户对底层表的访问权限，只暴露必要的数据和列给用户，对敏感数据进行保护。这样可以增强数据的安全性，确保只有被授权的用户能够访问和修改数据，减少了数据泄露和误操作的风险。
- 简化数据操作：视图可以隐藏底层表的复杂性，对用户提供逻辑上的简单化表达方式。通过视图，用户可以通过简单的查询来实现复杂的数据关联、过滤、分组等操作，无需手动编写复杂的查询语句，减少了用户的工作量和出错的可能性。
- 数据的定制化访问：视图允许根据特定需求创建对表的定制化访问方式。可以对底层表进行列过滤、列重命名、数据连接等操作，根据不同应用场景或用户需求，提供适合的数据视图，使数据展示更精准和易用。
- 提高性能和性能优化：视图可以预先定义、优化复杂的查询语句，并缓存查询结果，提高了查询性能。通过视图可以将常用的计算逻辑、筛选条件等预先定义好，避免了重复编写复杂的查询语句，提高了查询的效率。
总的来说，视图提供了简化数据访问、提高数据安全性、简化数据操作、定制化访问和性能优化等优点。通过视图，可以以更高效、安全和灵活的方式操作和管理数据库中的数据。
上述5点的列子：
Duplicate重复列：
2.索引：
什么是索引：
索引（Index）是关系型数据库中用于加快数据检索速度的一种数据结构。它是对表中的一个或多个列进行预排序的数据结构，类似于书籍的目录，可以加快查找、排序和过滤数据的效率。
索引的作用是提供一种快速访问数据的机制，通过创建索引，可以避免全表扫描，而是直接定位到满足查询条件的数据。索引可以使数据库在处理大量数据时更高效，减少查询时所需的磁盘访问次数。
在数据库中，索引是通过建立索引数据结构来实现的，常用的索引数据结构包括B-Tree、B+Tree、哈希索引等。这些数据结构可以根据索引列的值快速定位到存储位置。
索引可以基于一个或多个列构建，可以是唯一的（Unique Index），也可以允许重复值。通常，在经常被查询的列上创建索引可以提高查询性能，而对于很少使用或不需要检索的列，创建索引可能会带来额外的维护开销而不带来明显的性能提升。
然而，索引并非无代价的。在数据写入时，除了要操作数据表之外，还需要更新和维护索引，这会增加写入操作的开销。因此，过多或不适当地创建索引也可能会导致性能下降。
综上所述，索引是一种提高关系型数据库查询性能的重要方式，它通过预先排序和定位数据的方式加快了数据的检索速度。但需要权衡查询性能提升与索引维护开销之间的平衡，合理地创建和管理索引才能发挥其最大的作用。
为什么要使用索引：
使用索引有以下几个主要原因：
- 提高查询性能：索引可以大大提高数据库的查询性能。通过使用索引，数据库可以更快速地定位到满足查询条件的数据，而不需要进行全表扫描。这可以减少磁盘I/O操作的次数，提高查询的速度。
- 加快排序和聚合操作：如果一个查询需要对结果进行排序或聚合操作，索引的存在可以避免对所有数据进行排序或聚合，而是直接利用索引进行排序或聚合操作。这可以显著提高这些操作的性能。
- 减少磁盘I/O操作：索引的存在可以减少数据库对磁盘的I/O操作次数。当数据库需要读取或修改数据时，通过使用索引可以定位到数据所在的位置，而不需要扫描整个表。这减少了磁盘的读写次数，提高了数据库的性能。
- 优化查询计划和查询优化器：数据库查询优化器可以使用索引来生成最优的查询计划。通过使用索引，优化器可以选择更有效的查询策略，避免不必要的数据操作，提高查询性能。
- 提高并发性能：索引可以减少数据访问的冲突，提高数据库的并发性能。当多个用户同时访问数据库时，索引可以使数据的访问更加独立，减少数据锁定和竞争，提高数据库的并发处理能力。
需要注意的是，虽然索引可以提高查询性能，但创建索引也会带来一些开销。每当插入、更新或删除数据时，数据库还需要更新和维护索引。因此，在创建索引时需要权衡查询性能提升与维护成本之间的平衡，避免过度索引导致性能下降。
索引的优点和缺点：
索引在关系型数据库中有以下优点和缺点：
优点：
- 提高查询性能：索引可以大大提高查询的速度，通过使用索引，数据库可以快速定位到满足查询条件的数据，避免全表扫描，减少磁盘I/O操作的次数，提高查询效率。
- 优化排序和聚合操作：对于需要对结果进行排序或聚合的查询，索引可以加快这些操作的速度。索引能够直接提供有序数据，避免对全表进行排序或聚合。
- 提高并发性能：索引可以减少数据访问的冲突，提高并发处理性能。当多个用户同时访问数据库时，索引可以使数据的访问更加独立，减少数据锁定和竞争。
- 优化查询计划：数据库查询优化器可以使用索引来生成最优的查询计划，选择更有效的查询策略，避免不必要的数据操作，提高查询性能。
缺点：
- 占用存储空间：索引会占用额外的存储空间。对于大型表和复杂的索引，可能会消耗大量的存储空间，导致数据库的整体存储需求增加。
- 增加写操作的开销：每当插入、更新或删除数据时，数据库除了要操作数据表之外，还需要更新和维护索引。这会增加写入操作的开销。
- 索引维护成本：随着数据的不断变化，索引需要进行维护，包括重新构建、重新组织等操作。索引的维护可能会导致额外的性能消耗和资源占用。
- 可能导致查询性能下降：过多或不适当地创建索引可能导致查询性能下降。当索引过多时，数据库可能需要花费更多的时间来选择和使用最优的索引，而不是直接扫描数据。此外，索引也可能使得一些查询的执行计划更复杂，引入额外的开销。
综上所述，索引可以提高查询性能、排序和聚合操作的效率，优化查询计划和并发性能。但同时也会占用存储空间，增加写操作的开销，并需要维护成本。在使用索引时，需要权衡查询性能提升与维护成本之间的平衡，合理创建和管理索引。
什么时候不使用索引：
尽管索引可以提高数据库的查询性能，但在以下情况下可能需要谨慎或避免使用索引：
- 数据表较小：如果数据表的记录数较少，全表扫描的性能可能比使用索引更高效。在这种情况下，创建索引可能带来额外的维护成本而不带来明显的性能提升。
- 频繁进行写操作：如果数据表频繁进行插入、更新或删除操作，而且对查询性能的要求较低，那么创建索引可能会增加写操作的开销。频繁的更新可能导致大量的索引维护操作，影响整体性能。
- 数据分布不均匀：如果数据表中的数据分布不均匀，即某个索引列的值重复率很高，那么使用索引的效果可能不明显。因为索引在定位数据时是根据索引列的值来检索，如果数据重复率高，索引的选择性低，查询时可能仍然需要扫描大量的数据块。
- 较长的索引列：如果索引列的数据类型较长（如文本、大型对象），或者是复合索引中的某个长列，那么创建索引的存储空间开销会很大。此外，查询时需要比较更多的数据，导致查询效率下降。
- 需要频繁进行大规模数据的导入和删除：在需要频繁进行大规模数据的导入和删除操作时，索引的存在会增加导入和删除的开销，并可能导致索引碎片化。
需要根据具体的应用场景和需求来决定是否使用索引。在某些情况下，选择不使用索引可以降低维护成本，并保持数据库的性能和可维护性的平衡。综合考虑数据量、数据分布、读写比例等因素，权衡索引的优劣势，从而做出合理的决策。
索引什么时候失效：
索引在以下情况下可能会失效或不起作用：
- 不符合查询条件的操作：如果查询条件中不包含索引列或者使用了函数、表达式或者类型转换等操作，那么数据库可能无法使用索引进行快速定位数据，而需要进行全表扫描。
- 范围查询和排序操作：如果查询条件包含范围查询（如"<", “>”, "BETWEEN"等）或者需要对结果进行排序，索引的选择性可能会降低，数据库可能会选择进行全表扫描，而不是利用索引。
- 索引列的数据分布不均匀：如果索引列的数据分布不均匀，即某个索引列的值重复率很高，那么索引的选择性会降低。对于具有低选择性的索引，数据库可能不会优先选择使用索引。
- 更新频繁的列：如果某个列的值经常被更新，那么索引信息也需要相应地进行更新和维护，这会增加写操作的开销。在这种情况下，索引的维护成本可能会超过查询性能的提升，导致索引失去作用。
- 数据表较小：如果数据表的记录数较少，全表扫描的成本可能比使用索引更低。对于小表的查询，数据库可能会选择直接进行全表扫描，而不使用索引。
- 索引列顺序与查询条件不匹配：对于组合索引，索引列的顺序与查询条件的顺序不匹配时，索引可能无法被使用。数据库的查询优化器通常会根据查询条件的顺序选择合适的索引，如果索引列的顺序与查询条件不匹配，索引可能会失效。
- 索引统计信息不准确：数据库使用统计信息来选择最优的查询计划，如果索引的统计信息过时或不准确，数据库可能无法正确选择使用索引。
需要注意的是，不同的数据库系统可能在索引失效的具体情况上有所不同。在实际应用中，可以通过合理的设计和维护索引，配合数据库的查询优化工具来最大程度地保证索引的有效性。
普通索引：
-- 用时：26s SELECT * from t_log -- 使用索引之前的秒数：时间: 0.122s -- 使用索引用时：> 时间: 0.001s select * from t_log where moduleid ='10040199'; -- 构建索引用时间：> 时间: 0.892s create index idx_moduleid on t_log(moduleid)
调优：EXPLAIN
可以查看走过的索引：
唯一索引：
你所存在的列必然存储的所有的数据不可以有重复的：
主键索引：没有建立索引页很快：
组合索引：最左原则
走组合索引：
不走组合索引：
3.数据库的备份与恢复：
1.使用工具：navicat
-- 使用Navicat工具导入 t_log 共耗时 45s； -- 使用mysqldump导入 包含t_log表的整个数据库 共耗时 20s； -- 使用单表数据导入load data infile 的方式，共耗时 7.502s -- DELETE/TRUNCATE -- 花费的时间：10.597s DELETE FROM t_log; -- 花费的时间：0.121s TRUNCATE TABLE t_log;
2.导入导出：
-- 2导出 -- mysqldump -u用户名 -p密码 数据库名 > 数据库名.sql(这个名字随便叫) c:\mysql-8.0.13-winx64\bin>mysqldump -uroot -p123456 mybatis_ssm > 1234567.sql -- 3. 导入 -- 注意：首先建立空数据库 -- mysql>create database abc; -- 2.2.1 方法一 -- mysql>use abc; #选择数据库 -- mysql>set names utf8; #设置数据库编码 -- 导入数据 -- mysql>source /c:/mysql-8.0.13-winx64/bin/1234567.sql;
在Mysql中使用一直的方法导出一个18w的数据至少要用10-40秒而使用这个方法只需要一秒钟：
权限设置：
[mysql] # 设置mysql客户端默认字符集 default-character-set=utf8 [mysqld] secure_file_priv=C: #设置3306端口 port = 3306 # 设置mysql的安装目录 basedir=c:/mySQL/mysql-8.0.18-winx64 # 设置mysql数据库的数据的存放目录 datadir=c:/mySQL/mysql-8.0.18-winx64/data # 允许最大连接数 max_connections=200 # 服务端使用的字符集默认为8比特编码的latin1字符集 character-set-server=utf8 # 创建新表时将使用的默认存储引擎 default-storage-engine=INNODB
