MySQL 최적화의 가장 기본적인 작업을 요약합니다.-MySQL 튜토리얼-php.cn

최적화 아이디어

자세한 MySQL 최적화 단계는 다음과 같습니다.

데이터 테이블 구조를 확인하고 불완전한 디자인을 개선합니다.
본업을 운영하고 자주 사용되는 데이터베이스 쿼리 SQL을 수집
쿼리 SQL을 분석하고 적절하게 분할합니다. 인덱스 및 기타 최적화 쿼리를 추가합니다.
SQL을 최적화하는 동안 코드 로직을 최적화합니다.
로컬 캐시 및 Redis 캐시를 추가합니다.

NULL 값을 사용하지 마세요.

왜냐하면 테이블을 생성할 때 생성된 값에 기본값을 설정하지 않으면 MySQL은 기본값을 NULL로 설정합니다. 그렇다면 NULL을 사용하는 것이 좋지 않은 이유는 무엇입니까? NULL。那么为啥用NULL不好呢？

NULL使得索引维护更加复杂，强烈建议对索引列设置NOT NULL
NOT IN、!=等负向条件查询在有NULL值的情况下返回永远为空结果，查询容易出错
NULL列需要一个额外字节作为判断是否为NULL的标志位
使用NULL时和该列其他的值可能不是同种类型，导致问题。（在不同的语言中表现不一样）
MySQL难以优化对可为NULL的列的查询

所以对于那些以前偷懒的字段，手动设置一个默认值吧，空字符串呀，0呀补上。

虽然这种方法对于MySQL的性能来说没有提升多少，但是这是一个好习惯，而且以小见大，不要忽略这些细节。

添加索引

对于经常查询的字段，请加上索引，有索引和没有索引的查询速度相差十倍甚至更多。

一般来说，每张表都需要有一个主键id字段
常用于查询的字段应该设置索引
varchar类型的字段，在建立索引的时候，最好指定长度
查询有多个条件时，优先使用具有索引的条件
像LIKE条件这样的模糊搜索对于字段索引是无效的，需要另外建立关键词索引来解决
请尽量不要在数据库层面约束表和表之间的关系，这些表之间的依赖应该在代码层面去解决

当表和表之间有约束时，虽然增删查的SQL语句变简单了，但是带来的负面效果是插入等操作数据库都会去检查约束（虽然可以手动设置忽略约束），这样相当于把一些业务逻辑写到了数据库层，不便于维护。

优化表字段结构

数据库中那些可以用整形表示的数据就不要使用字符串类型，到底是用varchar还是char要看字段的可能值。

这种优化往往在数据库中有大量数据以后是不可行的，最好在数据库设计之前就设计好。

对于那些可能值很有限的列，使用tinyint代替VARCHAR，
- 比如记录移动设备平台，只有两个值：android，ios，那么就可以使用0表示android，1表示ios，这种列一定要写好注释
- 为什么不用ENUM呢？ENUM扩展困难，比如后来移动平台又增加了一个ipad，那岂不是懵逼了，而tinyint加个2就行，而且ENUM在代码里面处理起来特别奇怪，是当成整形呢还是字符串，各个语言不一样。
- 这种方式，一定要在数据库注释或者代码里面写明各个值的含义
对于那些定长字符串，可以使用char，比如邮编，总是5位
对于那些长度未知的字符串，使用varchar
不要滥用bigint，比如记录文章数目的表id字段，用int就行了，21亿篇文章上限够了
适当打破数据库范式添加冗余字段，避免查询时的表连接

查询的时候，肯定int类型比varchar

NULL은 인덱스 유지 관리를 더 복잡하게 만듭니다. 인덱스 열

🎜NOT IN, 에 대해 <code>NOT NULL을 설정하는 것이 좋습니다. != 및 기타 부정적인 조건부 쿼리는 NULL 값이 있는 경우 항상 빈 결과를 반환합니다. 쿼리는 오류가 발생하기 쉽습니다🎜🎜NULL 열에는 NULL의 플래그 비트 🎜🎜에 대해 NULL을 사용할 때 열의 다른 값과 동일한 유형이 아니어서 문제가 발생할 수 있는지 확인하기 위한 추가 바이트 . (언어마다 다르게 동작함) 🎜🎜MySQL은 NULL이 될 수 있는 열에 대한 쿼리를 최적화하는 데 어려움이 있습니다. 🎜🎜🎜그래서 이전에 게으른 필드의 경우 기본값인 null 문자 문자열을 수동으로 설정하세요. , 0을 추가합니다. 🎜🎜이 방법은 MySQL의 성능을 크게 향상시키지는 못하지만 좋은 습관이며 작은 일이 큰 일을 일어나게 하므로 이러한 세부 사항을 무시하지 마십시오. 🎜🎜🎜🎜색인 추가🎜🎜자주 쿼리되는 필드에는 인덱스를 추가하세요. 인덱스가 있는 경우와 없는 경우 쿼리 속도가 10배 이상 다릅니다. 🎜🎜🎜일반적으로 각 테이블에는 기본 키 id 필드가 있어야 합니다. 🎜🎜쿼리에 일반적으로 사용되는 필드는 인덱싱되어야 합니다. 🎜🎜varchar 유형 필드를 생성할 때 인덱싱할 때 , 길이를 지정하는 것이 가장 좋습니다🎜🎜쿼리에 조건이 여러 개인 경우 인덱스가 있는 조건이 선호됩니다🎜🎜 LIKE 조건과 같은 퍼지 검색은 필드 인덱스에 유효하지 않으며 추가 키를 설정해야 합니다. 해결해야 할 단어 인덱스🎜🎜데이터베이스 수준에서 테이블 간의 관계를 제한하지 않도록 하세요. 테이블 간의 종속성을 코드 수준에서 해결해야 합니다.🎜🎜🎜테이블 간에 문제가 있는 경우 제한, 추가, 삭제 및 쿼리의 SQL 문이 더 간단해지더라도 부정적인 효과는 데이터베이스가 삽입과 같은 작업에 대한 제약 조건을 확인한다는 것입니다(제약 조건을 무시하도록 수동으로 설정할 수 있음에도 불구하고). 데이터베이스 계층에 대한 비즈니스 로직을 쉽게 유지 관리할 수 있습니다. 🎜🎜🎜🎜테이블 필드 구조 최적화🎜🎜정수로 표시할 수 있는 데이터베이스의 데이터에 문자열 유형을 사용하지 마세요. varchar 또는 char를 사용할지 여부는 다음과 같습니다. 가능한 값입니다. 🎜🎜이런 종류의 최적화는 데이터베이스에 많은 양의 데이터가 있는 경우에는 가능하지 않은 경우가 많습니다. 데이터베이스를 설계하기 전에 먼저 설계하는 것이 가장 좋습니다. 🎜🎜🎜가능한 값이 매우 제한된 열의 경우 VARCHAR 대신 tinyint를 사용하세요. 🎜🎜예를 들어 모바일 장치 플랫폼을 기록하려면 android라는 두 가지 값만 있습니다. , ios, 그러면 0을 사용하여 android를 나타내고 1을 사용하여 ios를 나타낼 수 있습니다. 이런 유형의 열에는 주석을 잘 달아야 합니다🎜🎜 ENUM을 사용하면 어떨까요? 예를 들어 나중에 모바일 플랫폼에서 ipad를 추가하면 혼란스럽지 않을까요? 그런데 그냥 tinyint에 2를 추가하면 되나요? 및 ENUM은 코드에서 처리하기가 매우 이상합니다. 정수로 처리되는지 문자열로 처리되는지는 언어마다 다릅니다. 🎜🎜이 방법에서는 각 값의 의미를 데이터베이스 주석이나 코드에 적어야 합니다🎜🎜🎜🎜고정 길이 문자열의 경우 우편번호와 같은 char를 사용할 수 있습니다. 항상 5자리🎜 🎜길이를 알 수 없는 문자열의 경우 varchar를 사용하세요.🎜🎜테이블 id 필드와 같은 bigint를 남용하지 마세요. 기사 수를 기록하려면 int를 사용하세요. 상한은 21억 기사이면 충분합니다🎜🎜데이터베이스 패러다임을 제대로 깨고 쿼리 중 테이블 연결을 피하기 위해 중복 필드를 추가하세요🎜🎜🎜쿼리할 때, int 유형을 사용해야 합니다. varchar보다 빠릅니다. 왜냐하면 정수 비교는 기본 연산자를 직접 호출하여 수행할 수 있지만 문자열 비교에는 문자가 필요하기 때문입니다. 문자별 비교. 🎜🎜고정 길이 데이터 쿼리는 고정 길이 데이터와 데이터 사이의 오프셋이 고정되어 있기 때문에 가변 길이 데이터 쿼리보다 빠르고, 다음 데이터의 오프셋을 계산하기 쉽습니다. 가변 길이 데이터의 경우 다음 데이터의 오프셋을 쿼리하려면 한 단계가 더 필요합니다. 하지만. 고정 길이 데이터는 더 많은 저장 공간을 낭비할 수 있습니다. 🎜