다음 기사에서는 가장 자세한 MySQL 설계 및 개발 사양을 정리하여 여러분에게 도움이 되기를 바랍니다.
데이터베이스 개체는 데이터베이스의 구성 요소로, 테이블, 인덱스, 뷰, 다이어그램, 기본값, 규칙, 트리거, 사용자 등이 있습니다. , 등. 명명 규칙은 데이터베이스(SCHEMA), 테이블(TABLE), 인덱스(INDEX), 제약 조건(CONSTRAINTS) 등과 같은 데이터베이스 개체에 대한 명명 규칙을 나타냅니다. [추천: mysql 동영상 튜토리얼]
1. 의미 있는 영어 단어를 단어 중간에 밑줄로 구분하여 사용하세요
2. 이름 지정에는 밑줄을 사용할 수 있습니다.
3. 백업, 호출, 그룹 등과 같은 MySQL 예약어를 사용하지 마세요.
4 실제로 MySQL에서는 소문자를 사용할 수 있습니다. 대소문자 구분 여부를 설정합니다. 통일성을 보장하기 위해 여기서는 모든 소문자 표현을 표준화합니다.
1. 데이터베이스 이름은 30자를 초과할 수 없습니다.
2. 데이터베이스 이름은 일반적으로 프로젝트 이름 + 라이브러리의 의미를 나타내는 약어입니다. 예를 들어 IM 프로젝트의 워크플로 데이터베이스는 im_flow가 될 수 있습니다.
3. 데이터베이스 생성 시 기본 문자 집합 및 대조 규칙 절을 추가해야 합니다. 기본 문자 집합은 UTF8입니다(dumbo는 utf8mb4를 사용하도록 마이그레이션되었습니다).
4 이름은 소문자여야 합니다.
1. 일반 테이블 이름은 t_로 시작하고, t는 테이블의 의미를 나타내며, 명명 규칙은 t + 모듈(모듈 의미의 약어 포함) + 테이블(의 약어 포함)입니다. 테이블 의미), 예를 들어 사용자 모듈의 교육 정보 테이블: t_user_eduinfo.
2. 임시 테이블(RD, QA 또는 DBA 학생이 임시 데이터 처리를 위해 사용하는 테이블), 명명 규칙: 임시 접두사 + 모듈 + 테이블 + 날짜 접미사: temp_user_eduinfo_20210719temp_user_eduinfo_20210719
3、备份表（用于保存和归档历史数据或者作为灾备恢复的数据）命名规则，bak前缀+模块+表+日期后缀：bak_user_eduinfo_20210719
4、同一个模块的表尽可能使用相同的前缀，表名称尽可能表达含义
5、多个单词以下划线 _ 分隔
6、常规表表名尽量不超过30个字符，temp表和bak表视情况而定，也尽量简短为宜，命名应使用小写
1、字段命名需要表示其实际含义的英文单词或简写，单词之间用下划线 _ 进行连接，如 service_ip、service_port。
2、各表之间相同意义的字段必须同名，比如a表和b表都有创建时间，应该统一为create_time，不一致会很混乱。
3、多个单词以下划线 _ 分隔
4、字段名尽量不超过30个字符，命名应该使用小写
1、唯一索引使用uni + 字段名 来命名：create unique index uni_uid on t_user_basic(uid) 。
2、非唯一索引使用idx + 字段名 来命名：create index idx_uname_mobile on t_user_basic(uname,mobile) 。
3、多个单词以下划线 _ 分隔。
4、索引名尽量不超过50个字符，命名应该使用小写，组合索引的字段不宜太多，不然也不利于查询效率的提升。
5、多单词组成的列名，取尽可能代表意义的缩写，如 test_contact表member_id和friend_id上的组合索引：idx_mid_fid
bak_user_eduinfo_202107194. 동일한 모듈의 테이블은 와 동일한 이름을 사용해야 합니다. 테이블 이름은 최대한 의미를 표현합니다와 같이 단어는 밑줄(_)로 연결됩니다. >service_ip, service_port. 2. 테이블 간에 동일한 의미를 갖는 필드는 동일한 이름을 가져야 합니다. 예를 들어 테이블 a와 테이블 b는 모두 생성 시간을 가지며, 이는 create_time으로 통합되어야 합니다. 🎜🎜3. 여러 단어는 밑줄로 구분됩니다. _ 🎜🎜4. 필드 이름은 30자 이하여야 하며 이름은 소문자여야 합니다. 🎜🎜🎜🎜색인 명명 규칙🎜🎜1. 필드 이름: t_user_basic(uid)에 고유 인덱스 uni_uid를 생성합니다. 🎜🎜2. 고유하지 않은 인덱스는 idx + 필드 이름을 사용하여 이름이 지정됩니다: t_user_basic(uname,mobile)에 인덱스 idx_uname_mobile 생성. 🎜🎜3. 여러 단어는 밑줄 _로 구분됩니다. 🎜🎜4. 인덱스 이름은 50자를 초과할 수 없습니다. 결합된 인덱스의 필드는 소문자여야 합니다. 그렇지 않으면 쿼리 효율성을 높이는 데 도움이 되지 않습니다. 🎜🎜5 여러 단어로 구성된 열 이름의 경우 test_contact 테이블 member_id 및 friend_id의 결합 인덱스와 같이 최대한 많은 의미를 나타내는 약어를 사용하세요. :idx_mid_fid. 🎜🎜6. 결합 인덱스의 가장 왼쪽 접두사 원리를 이해하고 인덱스를 반복적으로 생성하지 마십시오. (a,b,c)가 생성되면 (a,b,c)가 생성됩니다. ). 🎜🎜🎜🎜뷰 이름 지정 규칙🎜🎜1. 뷰 이름은 뷰를 의미하는 v로 시작합니다. 전체 구조는 v + 뷰 내용의 의미의 약어입니다. 🎜🎜2. 뷰가 단일 테이블에서만 나오는 경우 v+테이블 이름입니다. 여러 테이블을 연관시켜 뷰를 생성한 경우에는 v + 밑줄(_)을 사용하여 여러 테이블 이름을 연결해야 하며, 뷰 이름은 30자를 넘지 않아야 합니다. 30자를 초과하는 경우 약어를 사용하세요. 🎜🎜3. 개발자는 특별한 필요 없이 뷰를 생성하는 것을 엄격히 금지합니다. 🎜🎜4. 이름은 소문자여야 합니다. 🎜1. 저장 프로시저 이름은 sp로 시작하는데 이는 저장 프로시저(storage Procedure)를 의미합니다. 여러 단어는 밑줄(_)로 연결됩니다. 저장 프로시저의 기능은 이름 지정에 반영되어야 합니다. 저장 프로시저 이름은 30자를 초과할 수 없습니다. storage procedure）。之后多个单词以下划线（_）进行连接。存储过程命名中应体现其功能。存储过程名尽量不能超过30个字符。
2、存储过程中的输入参数以i_开头，输出参数以o_开头。
3、命名应使用小写。
create procedure sp_multi_param(in i_id bigint,in i_name varchar(32),out o_memo varchar(100))
1、函数名以func开始，表示function。之后多个单词以下划线（_）进行连接，函数命名中应体现其功能。函数名尽量不超过30个字符。
2、命名应使用小写。
create function func_format_date(ctime datetime)
1、触发器以trig开头，表示trigger 触发器。
2、基本部分，描述触发器所加的表，触发器名尽量不超过30个字符。
3、后缀（_i,_u,_d）,表示触发条件的触发方式（insert,update或delete）。
4、命名应使用小写。
DROP TRIGGER IF EXISTS trig_attach_log_d;CREATE TRIGGER trig_attach_log_d AFTER DELETE ON t_dept FOR EACH ROW;
1、唯一约束：uk_表名称_字段名。uk是UNIQUE KEY的缩写。比如给一个部门的部门名称加上唯一约束，来保证不重名，如下：
ALTER TABLE t_dept ADD CONSTRAINT un_name UNIQUE(name);
2、外键约束：fk_表名，后面紧跟该外键所在的表名和对应的主表名（不含t_）。子表名和父表名用下划线(_)分隔。如下：
ALTER TABLE t_user ADD CONSTRAINT fk_user_dept FOREIGN KEY(depno) REFERENCES t_dept (id);
3、非空约束：如无特殊需要，建议所有字段默认非空(not null)，不同数据类型必须给出默认值(default)。
1 `id` int(11) NOT NULL,2 `name` varchar(30) DEFAULT '',3 `deptId` int(11) DEFAULT ,4 `salary` float DEFAULT NULL,
4、出于性能考虑，如无特殊需要，建议不使用外键。参照完整性由代码控制。这个也是我们普遍的做法，从程序角度进行完整性控制，但是如果不注意，也会产生脏数据。
5、命名应使用小写。
1、 生产使用的用户命名格式为 code_应用
2、 只读用户命名规则为 read_应用
1、如无特殊需求，必须使用innodb存储引擎。
可以通过 show variables like ‘default_storage_engine‘ 来查看当前默认引擎。主要有MyISAM 和 InnoDB，从5.5版本开始默认使用 InnoDB 引擎。点击这里进行刷题。
基本的差别为：MyISAM类型不支持事务处理等高级处理，而InnoDB类型支持。MyISAM类型的表强调的是性能，其执行速度比InnoDB类型更快，但是不提供事务支持，而InnoDB提供事务支持以及外部键等高级数据库功能。
1、如无特殊要求，必须使用utf8或utf8mb4。
在国内，选择对中文和各语言支持都非常完善的utf8格式是最好的方式，MySQL在5.5之后增加utf8mb4编码，mb4就是most bytes 4的意思，专门用来兼容四字节的unicode。
所以utf8mb4是utf8的超集，除了将编码改为utf8mb4外不需要做其他转换。当然，为了节省空间，一般情况下使用utf8也就够了。
可以使用如下脚本来查看数据库的编码格式
1 SHOW VARIABLES WHERE Variable_name LIKE 'character_set_%' OR Variable_name LIKE 'collation%';2 -- 或3 SHOW VARIABLES Like '%char%';
1、不同应用间所对应的数据库表之间的关联应尽可能减少，不允许使用外键对表之间进行关联，确保组件对应的表之间的独立性，为系统或表结构的重构提供可能性。目前业内的做法一般 由程序控制参照完整性。
2、表设计的角度不应该针对整个系统进行数据库设计，而应该根据系统架构中组件划分，针对每个组件所处理的业务进行数据库设计。
3、表必须要有PK，主键的优势是唯一标识、有效引用、高效检索，所以一般情况下尽量有主键字段。
4、一个字段只表示一个含义。
5、表不应该有重复列。
6、禁止使用复杂数据类型(数组,自定义等)，Json类型的使用视情况而定。
7、需要join
1 PRIMARY KEY (`id`),2 UNIQUE KEY `uni_brand_define` (`app_id`,`define_id`)
1 select brand_id,brand_name from ds_brand_system where status=? and define_id=? and app_id=?
trigger로 시작합니다. 이는 trigger 트리거를 의미합니다. 🎜🎜2. 기본적으로 트리거에 추가되는 테이블에 대해 설명합니다. 트리거 이름은 30자를 초과할 수 없습니다. 🎜🎜3. 트리거 조건의 트리거 방법(삽입, 업데이트 또는 삭제)을 나타내는 접미사(_i, _u, _d). 🎜🎜4. 이름은 소문자여야 합니다. 🎜1 select brand_id,brand_name from ds_brand_system where app_id=? and define_id=? and status=?
와 같은 변수 표시 'default_storage_engine'를 통해 현재 기본 엔진을 볼 수 있습니다. 주로 MyISAM과 InnoDB가 있습니다. 버전 5.5부터는 기본적으로 InnoDB 엔진을 사용합니다. 퀴즈를 연습하려면 여기를 클릭하세요. 🎜🎜기본적인 차이점은 MyISAM 유형은 트랜잭션 처리와 같은 고급 처리를 지원하지 않는 반면 InnoDB 유형은 지원한다는 것입니다. MyISAM 유형 테이블은 성능을 강조하며 InnoDB 유형보다 실행 속도가 빠르지만 트랜잭션 지원을 제공하지 않는 반면, InnoDB는 트랜잭션 지원을 제공합니다. 외래 키와 같은 고급 데이터베이스 기능도 있습니다. 🎜🎜🎜🎜문자셋 선택🎜🎜1. 특별한 요구사항이 없다면 utf8 또는 utf8mb4를 사용해야 합니다. 🎜🎜중국에서는 중국어와 다양한 언어를 완벽하게 지원하는 utf8 형식을 선택하는 것이 가장 좋습니다. MySQL은 5.5 이후에 utf8mb4 인코딩을 추가했습니다. /code>는 대부분의 바이트 4를 의미하며, 4바이트 유니코드와 호환되도록 특별히 설계되었습니다. 🎜🎜그래서 utf8mb4는 utf8의 상위 집합이며 인코딩을 utf8mb4로 변경하는 것 외에는 다른 변환이 필요하지 않습니다. 물론 공간을 절약하기 위해서는 일반적으로 utf8을 사용하는 것으로 충분합니다. 🎜🎜다음 스크립트를 사용하여 데이터베이스의 인코딩 형식을 볼 수 있습니다🎜rrreee🎜🎜🎜테이블 디자인 사양🎜🎜1. 서로 다른 애플리케이션에 해당하는 데이터베이스 테이블 간의 상관 관계는 최대한 최소화해야 하며, 외국어 사용은 테이블 간 키는 허용되지 않습니다. 구성 요소에 해당하는 테이블 간의 독립성을 보장하고 시스템 또는 테이블 구조를 재구성할 수 있는 가능성을 제공하기 위해 연결이 수행됩니다. 현재 업계 관행에는 일반적으로 참조 무결성에 대한 프로그래밍 방식의 제어가 포함됩니다. 🎜🎜2. 테이블 디자인의 관점에서 데이터베이스 디자인은 전체 시스템을 기반으로 하는 것이 아니라 시스템 아키텍처의 구성 요소 분할을 기반으로 해야 하며, 데이터베이스 디자인은 각 부분이 처리하는 비즈니스를 기반으로 해야 합니다. 요소. 🎜🎜3. 테이블에는 PK가 있어야 합니다. 기본 키의 장점은 고유 식별, 효과적인 참조 및 효율적인 검색이므로 일반적으로 기본 키 필드를 갖도록 노력하십시오. 🎜🎜4. 하나의 필드는 하나의 의미만을 나타냅니다. 🎜🎜5. 테이블에는 중복된 열이 있어서는 안 됩니다. 🎜🎜6. 복잡한 데이터 유형(배열, 사용자 정의 등)은 사용이 금지됩니다. Json 유형은 상황에 따라 다릅니다. 🎜🎜7. join이 필요한 필드(조인 키)의 데이터 유형은 암시적 변환을 방지하기 위해 절대적으로 일관되어야 합니다. 예를 들어, 연관된 필드는 모두 int 유형입니다. 🎜🎜8. 디자인은 최소한 세 번째 패러다임을 충족하고 데이터 중복을 최소화해야 합니다. 일부 특수 시나리오에서는 비정규화 설계를 허용하지만 중복 필드 설계는 프로젝트 검토 중에 설명해야 합니다. 🎜9. TEXT 필드는 대용량 텍스트로 저장되므로 독립된 테이블에 배치하고 PK를 사용하여 기본 테이블과 연결해야 합니다. 특별한 필요가 없는 경우 TEXT 및 BLOB 필드 사용은 금지됩니다. TEXT字段作为大体量文本存储，必须放在独立的表中 , 用PK与主表关联。如无特殊需要，禁止使用TEXT、BLOB字段。
10、需要定期删除(或者转移)过期数据的表，通过分表解决，我们的做法是按照2/8法则将操作频率较低的历史数据迁移到历史表中，按照时间或者则曾Id做切割点。
11、单表字段数不要太多，建议最多不要大于50个。过度的宽表对性能也是很大的影响。
12、MySQL在处理大表时，性能就开始明显降低，所以建议单表物理大小限制在16GB，表中数据行数控制在2000W内。
业内的规则是超过2000W性能开始明显降低。但是这个值是灵活的，你可以根据实际情况进行测试来判断，比如阿里的标准就是500W，百度的确是2000W。实际上是否宽表，单行数据所占用的空间都有起到作用的。
13、如果数据量或数据增长在前期规划时就较大，那么在设计评审时就应加入分表策略，后续会有专门的文章来分析数据拆分的做法：垂直拆分（垂直分库和垂直分表）、水平拆分（分库分表和库内分表）；
14、无特殊需求，严禁使用分区表
1、INT：如无特殊需要，存放整型数字使用UNSIGNED INT型，整型字段后的数字代表显示长度。比如 id int(11) NOT NULL
2、DATETIME：所有需要精确到时间(时分秒)的字段均使用DATETIME,不要使用TIMESTAMP类型。
对于TIMESTAMP，它把写入的时间从当前时区转化为UTC（世界标准时间）进行存储。查询时，将其又转化为客户端当前时区进行返回。而对于DATETIME，不做任何改变，基本上是原样输入和输出。
另外DATETIME存储的范围也比较大：
timestamp所能存储的时间范围为：’1970-01-01 00:00:01.000000’ 到 ‘2038-01-19 03:14:07.999999’。
datetime所能存储的时间范围为：’1000-01-01 00:00:00.000000’ 到 ‘9999-12-31 23:59:59.999999’。
但是特殊情况，对于跨时区的业务，TIMESTAMP更为合适。
3、VARCHAR：所有动态长度字符串 全部使用VARCHAR类型,类似于状态等有限类别的字段,也使用可以比较明显表示出实际意义的字符串,而不应该使用INT之类的数字来代替；VARCHAR(N)，
N表示的是字符数而不是字节数。比如VARCHAR(255)，可以最大可存储255个字符（字符包括英文字母，汉字，特殊字符等）。但N应尽可能小，因为MySQL一个表中所有的VARCHAR字段最大长度是65535个字节，且存储字符个数由所选字符集决定。
如UTF8存储一个字符最大要3个字节，那么varchar在存放占用3个字节长度的字符时不应超过21845个字符。同时，在进行排序和创建临时表一类的内存操作时，会使用N的长度申请内存。(如无特殊需要，原则上单个varchar型字段不允许超过255个字符)
4、TEXT：仅仅当字符数量可能超过20000个的时候,才可以使用TEXT类型来存放字符类数据,因为所有MySQL数据库都会使用UTF8字符集。
所有使用TEXT类型的字段必须和原表进行分拆，与原表主键单独组成另外一个表进行存放，与大文本字段的隔离，目的是。如无特殊需要，不使用MEDIUMTEXT、TEXT、LONGTEXT类型
5、对于精确浮点型数据存储，需要使用DECIMAL，严禁使用FLOAT和DOUBLE。
6、如无特殊需要，尽量不使用BLOB类型
7、如无特殊需要，字段建议使用NOT NULL属性，可用默认值代替NULL
8、自增字段类型必须是整型且必须为UNSIGNED，推荐类型为INT或BIGINT，并且自增字段必须是主键或者主键的一部分。
1、索引区分度
索引必须创建在索引选择性（区分度）较高的列上，选择性的计算方式为: selecttivity = count(distinct c_name)/count(*)
INT: 특별한 필요가 없으면 UNSIGNED INT 유형을 사용하여 정수를 저장합니다. , 정수 필드 뒤의 숫자는 디스플레이 길이를 나타냅니다. 예를 들어, id int(11) NOT NULL🎜🎜2, DATETIME: 시간(시, 분)이 정확해야 하는 모든 필드 및 초) DATETIME을 사용하고, TIMESTAMP 유형을 사용하지 마세요. 🎜🎜TIMESTAMP의 경우 작성된 시간을 현재 시간대에서 UTC(Universal Coordinated Time)로 변환하여 저장합니다. 쿼리 시 클라이언트의 현재 시간대로 변환하여 반환한다. DATETIME의 경우 변경 사항이 없으며 입력과 출력은 기본적으로 동일합니다. 🎜🎜또한 DATETIME의 저장 범위도 상대적으로 큽니다. 🎜🎜timestamp가 저장할 수 있는 시간 범위는 '1970-01-01 00:00: 01.000000' ~' 2038-01-19 03:14:07.999999'. 🎜🎜 datetime이 저장할 수 있는 시간 범위는 '1000-01-01 00:00:00.000000' ~ '9999-12-31 23:59:59.999999'입니다. 🎜🎜그러나 특별한 경우, 시간대가 다른 비즈니스의 경우 TIMESTAMP가 더 적합합니다. 🎜🎜3. VARCHAR: 모든 동적 길이 문자열은 상태와 같은 제한된 범주의 필드와 유사한 VARCHAR 유형을 사용하며 실제 의미를 명확하게 표현할 수 있는 문자도 사용합니다. . 문자열은 INT와 같은 숫자로 대체되어서는 안 됩니다. 🎜🎜N은 바이트 수가 아닌 문자 수를 나타냅니다. 예를 들어 VARCHAR(255)는 최대 255자까지 저장할 수 있습니다(문자에는 영문자, 한자, 특수문자 등이 포함됩니다). 그러나 N은 가능한 한 작아야 합니다. 왜냐하면 MySQL 테이블의 모든 VARCHAR 필드의 최대 길이는 65535바이트이고 저장된 문자 수는 선택한 문자 집합에 따라 결정되기 때문입니다. 🎜🎜예를 들어 UTF8에서는 문자 하나를 저장하는 데 최대 3바이트가 필요하므로 varchar는 3바이트를 차지하는 문자를 저장할 때 21845자를 초과해서는 안 됩니다. 동시에 임시 테이블 정렬 및 생성과 같은 메모리 작업을 수행할 때 N 길이는 메모리를 적용하는 데 사용됩니다. (특별한 필요가 없는 경우 원칙적으로 단일 varchar 필드는 255자를 초과할 수 없습니다)🎜🎜4. TEXT: 문자 수를 초과할 수 없는 경우에만 20,000을 초과하면 모든 MySQL 데이터베이스는 UTF8 문자 집합을 사용하므로 문자 데이터를 저장하는 데 TEXT 유형만 사용할 수 있습니다. 🎜🎜TEXT 유형을 사용하는 모든 필드는 원본 테이블에서 분할되어야 하며 원본 테이블의 기본 키와 결합하여 저장을 위한 또 다른 테이블을 형성하고 큰 텍스트 필드와 격리되어야 합니다. 특별한 필요가 없다면 MEDIUMTEXT, TEXT, LONGTEXT 유형을 사용하지 마세요🎜🎜5. 정확한 부동 소수점 데이터 저장을 위해서는 DECIMAL을 사용해야 하며 FLOAT 및 DOUBLE의 사용은 엄격히 금지됩니다. 🎜🎜6. 특별한 필요가 없으면 BLOB 유형을 사용하지 마세요. 🎜🎜7. 특별한 필요가 없으면 NOT NULL을 사용하는 것이 좋습니다. > 속성이며 NULL🎜🎜8 대신 기본값을 사용할 수 있습니다. 자동 증가 필드 유형은 정수여야 하며 UNSIGNED여야 합니다. 권장 유형은 INT 또는 BIGINT 이고 자동 증가 필드는 기본 키이거나 기본 키의 일부여야 합니다. 🎜selecttivity = count(distinct c_name)/count(*); 판별 결과가 0.2 미만인 경우 이 열에 인덱스를 생성하지 않는 것이 좋습니다. , 그렇지 않으면 커집니다. SQL 실행 속도가 느려질 가능성이 있습니다🎜🎜2. 가장 왼쪽 접두사를 따르세요🎜.对于确定需要组成组合索引的多个字段，设计时建议将选择性高的字段靠前放。使用时，组合索引的首字段，必须在where条件中，且需要按照最左前缀规则去匹配。
3、禁止使用外键，可以在程序级别来约束完整性
4、Text类型字段如果需要创建索引，必须使用前缀索引
5、单张表的索引数量理论上应控制在5个以内。经常有大批量插入、更新操作表，应尽量少建索引，索引建立的原则理论上是多读少写的场景。
6、ORDER BY，GROUP BY，DISTINCT的字段需要添加在索引的后面，形成覆盖索引
7、正确理解和计算索引字段的区分度，文中有计算规则，区分度高的索引，可以快速得定位数据，区分度太低，无法有效的利用索引，可能需要扫描大量数据页，和不使用索引没什么差别。
8、正确理解和计算前缀索引的字段长度，文中有判断规则，合适的长度要保证高的区分度和最恰当的索引存储容量，只有达到最佳状态，才是保证高效率的索引。
9、联合索引注意最左匹配原则：必须按照从左到右的顺序匹配，MySQL会一直向右匹配索引直到遇到范围查询(>、<、between、like)然后停止匹配。
如：depno=1 and empname>'' and job=1 如果建立(<code>depno,empname,job)顺序的索引，job是用不到索引的。
10、应需而取策略，查询记录的时候，不要一上来就使用*，只取需要的数据，可能的话尽量只利用索引覆盖，可以减少回表操作，提升效率。
11、正确判断是否使用联合索引（上面联合索引的使用那一小节有说明判断规则），也可以进一步分析到索引下推（IPC），减少回表操作，提升效率。
12、避免索引失效的原则：禁止对索引字段使用函数、运算符操作，会使索引失效。这是实际上就是需要保证索引所对应字段的”干净度“。
13、避免非必要的类型转换，字符串字段使用数值进行比较的时候会导致索引无效。
14、模糊查询’%value%’会使索引无效，变为全表扫描，因为无法判断扫描的区间，但是’value%’是可以有效利用索引。
15、索引覆盖排序字段，这样可以减少排序步骤，提升查询效率
16、尽量的扩展索引，非必要不新建索引。比如表中已经有a的索引，现在要加(a,b)的索引，那么只需要修改原来的索引即可。
举例子：比如一个品牌表，建立的的索引如下，一个主键索引，一个唯一索引
1 PRIMARY KEY (`id`),2 UNIQUE KEY `uni_brand_define` (`app_id`,`define_id`)
当你同事业务代码中的检索语句如下的时候，应该立即警告了，即没有覆盖索引，也没按照最左前缀原则：
1 select brand_id,brand_name from ds_brand_system where status=? and define_id=? and app_id=?
建议改成如下：
1 select brand_id,brand_name from ds_brand_system where app_id=? and define_id=? and status=?
1、PK应该是有序并且无意义的，由开发人员自定义，尽可能简短，并且是自增序列。
2、表中除PK以外,还存在唯一性约束的,可以在数据库中创建以“uk_”作为前缀的唯一约束索引。
3、PK字段不允许更新。
4、禁止创建外键约束，外键约束由程序控制。
5、如无特殊需要，所有字段必须添加非空约束，即not null。
6、如无特殊需要，所有字段必须有默认值。
1、尽量避免使用select *，join语句使用select *可能导致只需要访问索引即可完成的查询需要回表取数。
一种是可能取出很多不需要的数据，对于宽表来说，这是灾难；一种是尽可能避免回表，因为取一些根本不需要的数据而回表导致性能低下，是很不合算。
2、严禁使用 select * from t_name ，而不加任何where条件，道理一样，这样会变成全表全字段扫描。
3、MySQL中的text类型字段存储：
3.1、不与其他普通字段存放在一起,因为读取效率低，也会影响其他轻量字段存取效率。
3.2、如果不需要text类型字段，又使用了select *，会让该执行消耗大量io，效率也很低下
4. 관련 함수를 사용하여 필드를 추출할 수 있지만 now() , rand() , sysdate() 는 최대한 피해야 합니다. 가능한 한 결과가 불확실한 함수의 경우 Where 조건의 필터 조건 필드에는 데이터 유형 변환 함수를 포함한 모든 함수의 사용을 엄격히 금지합니다. 계산 및 변환 횟수가 많으면 비효율성이 발생하며 이는 지수에도 설명되어 있습니다. now() , rand() , sysdate() 等不确定结果的函数，在Where条件中的过滤条件字段上严禁使用任何函数，包括数据类型转换函数。大量的计算和转换会造成效率低下，这个在索引那边也描述过了。
5、分页查询语句全部都需要带有排序条件 , 否则很容易引起乱序
6、用in()/union替换or，效率会好一些，并注意in的个数小于300
7、严禁使用%前缀进行模糊前缀查询:如：select a,b,c from t_name where a like ‘%name’; 可以使用%模糊后缀查询如：select a,b from t_name where a like ‘name%’;
8、避免使用子查询，可以把子查询优化为join操作
通常子查询在in子句中，且子查询中为简单SQL(不包含union、group by、order by、limit从句)时，才可以把子查询转化为关联查询进行优化。
子查询性能差的原因：
· 子查询的结果集无法使用索引，通常子查询的结果集就会被存储到临时表中，不论是内存临时表还是磁盘临时表都不会存在索引，所以查询性能 会受到一定的影响；
· 特别是对于返回结果集比较大的子查询，其对查询性能的影响也就越大；
· 由于子查询会产生大量的临时表也没有索引，所以会消耗过多的CPU和IO资源，产生大量的慢查询。
1、禁止使用不含字段列表的INSERT语句
如：insert into values ('a','b','c'); 应使用 insert into t_name(c1,c2,c3) values ('a','b','c'); 。
2、大批量写操作（UPDATE、DELETE、INSERT），需要分批多次进行操作
· 大批量操作可能会造成严重的主从延迟，特别是主从模式下，大批量操作可能会造成严重的主从延迟，因为需要slave从master的binlog中读取日志来进行数据同步。
· binlog日志为row
or를 대체하려면 in()/union을 사용하세요. 효율성을 높이세요. in의 수가 300🎜🎜7 미만이라는 점에 유의하세요. 퍼지 접두사 쿼리에 % 접두사를 사용하는 것은 엄격히 금지됩니다. 예: select a,b,c from t_name where a like '%name'; OK 다음과 같은 % 퍼지 접미사 쿼리를 사용하세요. select a,b from t_name where a like 'name%';🎜🎜8 하위 쿼리를 joinOperation🎜🎜으로 최적화합니다. 일반적으로 하위 쿼리는 in 절에 있고 하위 쿼리는 간단한 SQL입니다(union 제외, group by 제외). , order by, limit 절), 하위 쿼리를 관련 쿼리로 변환하여 최적화할 수 있습니다. 🎜🎜하위 쿼리 성능이 저하되는 이유: 🎜🎜· 하위 쿼리의 결과 집합은 인덱스를 사용할 수 없습니다. 일반적으로 하위 쿼리의 결과 집합은 임시 테이블인지 여부에 관계없이 임시 테이블에 저장됩니다. 메모리 또는 디스크 임시 테이블에는 인덱스가 없으므로 쿼리 성능이 어느 정도 영향을 받습니다. 🎜🎜· 특히 더 큰 결과 집합을 반환하는 하위 쿼리의 경우 쿼리 성능에 미치는 영향이 더 커집니다. 🎜🎜· 하위 쿼리는 인덱스 없이 임시 테이블을 많이 생성하므로 CPU 및 IO 리소스를 너무 많이 소비하고 느린 쿼리를 많이 생성합니다. 🎜값에 삽입 ('a','b','c')는 t_name(c1,c2,c3) 값에 삽입 (' a','b ','c');. 🎜🎜2. 대규모 일괄 쓰기 작업(UPDATE, DELETE, INSERT)은 일괄적으로 여러 번 수행되어야 합니다🎜🎜· 대용량 작업은 특히 마스터-슬레이브 모드에서 심각한 마스터-슬레이브 지연을 일으킬 수 있습니다. 슬레이브가 master 데이터 동기화를 위해 의 binlog에서 로그를 읽습니다. 🎜🎜· binlog 로그가 행 형식일 경우 대량의 로그가 생성됩니다🎜위 내용은 가장 상세한 MySQ 설계 및 개발 사양 [추천 모음]의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
