MySQL 최적화의 가장 기본적인 작업을 요약합니다.

                                                                                                               

최적화 아이디어

자세한 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보다 빠릅니다. 왜냐하면 정수 비교는 기본 연산자를 직접 호출하여 수행할 수 있지만 문자열 비교에는 문자가 필요하기 때문입니다. 문자별 비교. 🎜🎜고정 길이 데이터 쿼리는 고정 길이 데이터와 데이터 사이의 오프셋이 고정되어 있기 때문에 가변 길이 데이터 쿼리보다 빠르고, 다음 데이터의 오프셋을 계산하기 쉽습니다. 가변 길이 데이터의 경우 다음 데이터의 오프셋을 쿼리하려면 한 단계가 더 필요합니다. 하지만. 고정 길이 데이터는 더 많은 저장 공간을 낭비할 수 있습니다. 🎜

대형 테이블 분할

데이터 양이 가까운 미래에 500만 개를 초과하거나 빠르게 증가할 수 있는 테이블의 경우, 데이터 양이 100만 개를 초과할 경우 미리 테이블을 수직 또는 수평으로 분할해야 합니다. 명백한 쇠퇴.

데이터베이스 설계 초기 단계에서 하위 데이터베이스 및 하위 테이블에 대한 계획을 확정하십시오. 그렇지 않으면 코드 복잡성이 크게 증가하고 나중에 변경하기가 어려워집니다.

수직 테이블 파티셔닝은 날짜와 같은 외부 변수를 기반으로 하며, 수평 테이블 파티셔닝은 테이블의 특정 필드 관계를 기반으로 하며 해시 매핑을 사용하여 테이블을 동일한 부분으로 나눕니다.

하위 데이터베이스와 테이블 하위 데이터베이스의 전제 조건은 쿼리 문을 실행하기 전에 쿼리할 데이터가 어느 하위 데이터베이스와 어느 하위 테이블에 포함될 수 있는지를 이미 알고 있다는 것입니다.

쿼리 문 최적화

이것은 많은 시스템에서 데이터베이스 병목 현상의 시작점입니다.

• 간단한 쿼리를 사용하고 테이블 링크 사용을 피하세요.
• 전체 테이블 스캔을 피하세요.
  LIKE

사용

항등 연산자(, !=) 사용

LIKE

使用不等操作符（、!=）

查询含有is null的列

在非索引列上使用oris null이 포함된 열 쿼리

인덱싱되지 않은 열에 또는 사용

여러 조건으로 쿼리할 때는 간단한 쿼리 조건이나 인덱스 컬럼 쿼리를 앞에 넣어주세요

• 쿼리해야 할 컬럼을 지정해 보시고, 게으르지 말고 select *
• 를 사용해 보세요. 지정하지 않으면 한편으로는 중복 데이터, 점유 대역폭 등이 반환됩니다.

한편, MySQL이 쿼리를 실행할 때 필드가 없으면 먼저 테이블의 필드를 쿼리합니다. 구조

대문자의 쿼리 키워드는 소문자의 쿼리 키워드보다 약간 빠릅니다.

하위 쿼리를 사용하면 임시 테이블 생성이 JOIN 및 UNION보다 약간 느릴 것입니다.

인덱스 필드를 쿼리할 때는 데이터베이스 함수를 사용하지 마십시오. 쿼리 결과를 캐싱하는 것은 불편합니다

한 행의 데이터만 필요한 경우 LIMIT를 사용하십시오. 1. 데이터가 너무 많으면 LIMIT를 적절하게 설정하고 페이징 쿼리를 수행하십시오.

ORDER BY RAND()를 사용하지 않으면 성능이 매우 낮습니다.

캐시 추가

Redis 및 기타 캐시는 물론 로컬 파일 캐시 등을 사용하면 데이터베이스 쿼리 수를 크게 줄일 수 있습니다. 캐싱에 관해서는 자신의 시스템의 데이터 특성을 분석하고 적절한 선택을 해야 합니다.
• 구성 정보 등 일반적으로 사용되는 일부 데이터는 캐시에 저장될 수 있습니다.
• 데이터베이스의 테이블 구조는 로컬로 캐시될 수 있습니다.
• 캐시된 데이터는 적시에 업데이트되어야 하며 유효성이 유지되어야 합니다.

캐시를 늘려야 합니다. 시스템 복잡도를 높이려면 트레이드오프에 주의하세요

데이터 테이블 구조를 확인하세요추천 학습: "

mysql 비디오 튜토리얼🎜 "🎜

위 내용은 MySQL 최적화의 가장 기본적인 작업을 요약합니다.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!