매우 좋아하는 공유: 프로덕션에 부합하는 MySQL 최적화 아이디어

                                                                                                               

머리말

이 글을 쓰는 출발점은 제가 직장에서 데이터를 다루며 쌓아온 경험을 기록하는 것입니다. 글을 쓰면서 모든 지점에서 최적화 시 최적화의 필요성과 같은 다른 배경 지식이 파생된다는 것을 알게 되었습니다. 느린 쿼리, 설명 및 기타 관련 기능에 대해 어느 정도 이해하고 있어야 합니다. 예를 들어 Elasticsearch를 도입하려면 데이터 동기화 문제 해결, Elasticsearch 지식 학습 등이 필요합니다. 기사가 길어서 모든 사항을 자세히 설명하는 것은 불가능합니다. 비디오 튜토리얼처럼 저는 제한된 지식을 바탕으로 몇 가지 일반적인 사항을 요약할 뿐입니다. 그럼에도 불구하고 이미 글의 길이가 매우 깁니다. 특정 사항에 관심이 있는 경우 Baidu/Google에 가서 개별 세부 사항에 대한 심층적인 지식을 얻으시기 바랍니다.

글이 꽤 길기 때문에 관심 있으신 분들은 한 번 읽어보시면 좋을 것 같습니다. [추천 학습: "mysql 동영상 튜토리얼"]

생각하는 관점

데이터베이스 기술은 지금까지 수동 관리 단계, 파일 시스템 단계, 데이터베이스 시스템 단계를 거쳤습니다.

소프트웨어 시스템이 없던 초기에는 수동 회계와 구두 합의라는 수동 관리 단계를 거쳐 현실 세계에서 특정 사업을 운영하는 것이 가능했지만 이런 형태는 오래전부터 존재해왔으며 상대적으로 비효율적이었습니다. 해결책. . 다음 단계에서는 컴퓨터 기술의 발달로 수동회계를 엑셀 테이블로 대체하는 파일 시스템 단계가 있었는데, 이는 어느 정도 생산성을 향상시켰다. 조작이 간단하고 효율성이 높은 데이터베이스 시스템인 소프트웨어 시스템 단계에서는 생산성이 다시 향상되었으며, 현실 세계의 특정 문제가 데이터로 추상화되고, 데이터의 흐름과 변화를 통해 현실 세계의 비즈니스가 표현됩니다. 소프트웨어 시스템에서 데이터 저장소는 일반적으로 관계형 데이터베이스와 여러 비관계형 데이터베이스로 구성됩니다.

데이터베이스는 시스템 비즈니스와 밀접한 관련이 있습니다. 이를 위해서는 제품 관리자가 비즈니스를 설계할 때 데이터 저장 및 쿼리 프로세스를 이해해야 합니다. 비즈니스 변경이 데이터베이스에 어떤 영향을 미칠지 명확합니다. 새로운 참조 자료를 참조해야 하는지 여부. 예를 들어 제품 관리자가 설계한 업무는 단일 테이블 볼륨이 수백만 개에 달하는 여러 MySQL 테이블에 대한 통계 분석 및 데이터 요약을 수행하는 것입니다. MySQL 다중 테이블 쿼리를 직접 사용하면 느린 쿼리가 발생하여 msyql이 발생하게 됩니다. 이 경우 해결책은 제품 측면에서 타협하거나 기술 스택을 변경하는 것입니다.

시스템 아키텍처 및 데이터베이스 솔루션에서는 회사의 팀 역량에 더 적합한 것을 선택해야 합니다. 시스템 초기 단계에서는 지폐 기능을 갖춘 간단한 데이터베이스 최적화가 가장 비용 효율적인 솔루션이 될 것입니다. mysql 데이터베이스 지폐 기능이 무력할 때 핵심 기능을 갖춘 핵심 소프트웨어 서비스를 도입하는 것이 가장 비용 효율적인 솔루션이 될 것입니다. 문제가 발생했을 때 적절한 솔루션을 선택하는 방법은 귀하의 가치를 반영할 때입니다.

가난한 소년이 부자 소녀와 사랑에 빠진다. 단기적인 달콤함은 실제 계급 불평등을 따라잡을 수 없다. 해피엔딩은 가난한 소년의 환상과 야오 선생님의 TV 시리즈에만 존재한다.

제한된 비용으로 데이터 저장 성능을 향상시키는 방법이 이 글의 핵심 아이디어입니다.

배경 지식

모든 사람이 일상 업무에서 다음 콘텐츠를 자주 접하게 될 것이라고 생각합니다.

관계형 데이터베이스

관계형 데이터베이스는 2차원 테이블과 테이블 간의 연결로 구성된 데이터 조직으로 소프트웨어에 대한 트랜잭션 데이터 일관성, 데이터 지속성 등의 기능을 제공하며 소프트웨어 시스템의 핵심 저장소입니다. 서비스는 개발 및 인터뷰 중에 가장 자주 접하게 되는 데이터베이스입니다. 일부 소규모 아웃소싱 프로젝트의 경우 MySQL은 모든 비즈니스 요구 사항을 충족하기에 충분합니다. 이는 우리가 자주 접하게 되는 것이며 실제로는 트릭으로 가득 차 있습니다. 다음 장에서 그 트릭에 대해 자세히 논의하겠습니다.
장점:

1. 트랜잭션
2. 지속성
3. 상대적으로 일반적인 SQL 언어

문제

1. 하드 디스크 I/O 요구 사항이 매우 높음
2. 대용량 데이터의 집계 쿼리가 비효율적임
3. 인덱스 누락
4. 인덱스 왼쪽 최장 일치 원칙으로 인해 전체 텍스트 검색을 수행하는 것이 부적절함
5. 트랜잭션을 잘못 사용하면 잠금이 발생할 수 있음 혼잡
6. 레벨 확장으로 인해 발생하는 다양한 문제는 처리하기 어렵습니다

비관계형 데이터베이스 - NoSql

MySQL 데이터베이스는 관계형 데이터 저장 소프트웨어로서 장점과 단점이 뚜렷하므로 소프트웨어에 포함되는 데이터의 양이 일반적으로 시스템이 지속적으로 증가하고 비즈니스 복잡성이 계속 증가하면 MySQL 데이터베이스의 기능을 향상하여 모든 문제를 해결할 수는 없으며 대신 다른 스토리지 소프트웨어를 도입하고 다양한 유형의 NoSQL을 사용하여 지속적인 문제를 해결해야 합니다. 소프트웨어 시스템 데이터의 양이 늘어나고 비즈니스가 복잡해집니다. 홍보에 문제가 없습니다.
관계형 데이터베이스는 다양한 시나리오에서 관계형 데이터베이스를 최적화한 것입니다. 어떤 종류의 NoSQL을 도입한다고 해서 모든 것이 괜찮을 것이라는 의미는 아닙니다. 즉, 시장에서 NoSQL의 유형과 적용의 어려움을 완전히 이해하고 선택해야 한다는 의미입니다. 적절한 시나리오에서는 적절한 스토리지 소프트웨어를 사용하는 것이 좋습니다.

Key-Value 유형

비즈니스에서는 특정 테이블의 내용을 쿼리하는 경우가 많지만 쿼리 결과는 대부분 변경되지 않으므로 Memcached 및 Redis와 같은 Key-value가 등장했습니다. 시스템에서 널리 사용됩니다. Redis는 Memcached보다 더 많은 데이터 구조와 지속성을 가지고 있어 KV형 NoSQL 중에서 가장 널리 사용됩니다.

검색 유형

전체 텍스트 검색 시나리오에서는 쿼리와 같은 MySQLB+ 트리 인덱스의 쿼리 최적화가 인덱스에 도달할 수 없습니다. 모든 유사 키워드 쿼리는 수만 개의 데이터가 있는 테이블에서 전체 테이블 검색입니다. 여전히 지원 가능하지만, 비즈니스 코드가 제대로 작성되지 않아 트랜잭션에서 Like 쿼리가 호출되면 데이터를 저장할 때 쿼리가 느려집니다. 역인덱스를 핵심으로 하는 ElasticSearch는 전체 텍스트 검색 시나리오를 완벽하게 충족할 수 있습니다. 동시에 ElasticSearch는 대용량 데이터도 매우 잘 지원하며, 문서화 및 생태도 매우 우수한 검색 제품입니다. 유형.

문서 유형

문서 유형 NoSql은 반구조화된 데이터를 문서로 저장하는 NoSql 유형을 의미합니다. 일반적으로 문서 유형 NoSql은 데이터를 JSON 또는 XML 형식으로 저장하므로 스키마가 없습니다. 스키마의 특성상 데이터를 마음대로 저장하고 읽을 수 있으므로 문서 기반 NoSql의 등장으로 관계형 데이터베이스 테이블 구조의 불편한 확장 문제가 해결되었습니다. 저자는

열 공식

을 사용한 적이 없습니다. 특정 규모의 기업의 경우 비즈니스에 실시간 및 유연한 데이터 요약이 포함되는 경우가 많습니다. 이러한 종류의 비즈니스는 사전 계산 솔루션으로 해결하기에 적합하지 않습니다. 사전에 계산하고 요약하는 계획을 사용하여 사업을 작성했지만, 요약된 데이터의 양이 증가함에 따라 요약된 데이터를 축적하는 마지막 단계가 점차적으로 매우 느려지는 것이 이 시나리오의 산물입니다. 빅데이터 시대의 가장 대표적인 기술 중 하나가 바로 HBase인데, HBase의 적용이 매우 무거워서 실행하려면 완전한 Hadoop 생태계 세트가 필요한 경우가 많습니다. 명령문용 MySql 쿼리와 호환됩니다. 요약 + 컬럼 저장 소프트웨어의 강력한 쿼리 기능은 다양한 실시간 및 유연한 데이터 요약 서비스를 지원하기에 충분합니다.

사례

2021년을 시점으로 대부분의 시스템은 초기 단계에서 다음과 같은 계획으로 시작합니다. 다음으로 이 경우에는 약간의 조정을 하게 됩니다.

시간이 지날수록 하드웨어 업그레이드로 얻는 이점은 줄어듭니다. 시간과 인력이 부족할 때 가장 빠른 최적화 솔루션입니다. 소프트웨어 최적화로 인해 얻을 수 있는 이점은 미래에 더 높지만 필요한 기술 인력의 수준도 미래에 더 높습니다. 시간과 인력이 허용된다면 이는 가장 비용 효율적인 최적화 솔루션입니다. 하드웨어와 소프트웨어 최적화는 상호 배타적이지 않습니다. 필요한 경우 둘 다 동시에 MYSQL 성능의 상한에 접근할 수 있습니다.

하드 최적화 - 현금 능력

• 1단계

  • 디스크 I/O 개선, SSD 디스크 사용 시도(질적 개선)
  • 메모리 늘리기, 쿼리 캐시 공간 늘리기
  • CPU 번호 늘리기 코어 수, 실행 스레드 증가

• 2단계

  • 자체 구축된 mysql을 서비스 공급자 mysql 서비스로 교체
  • 내장된 읽기 및 쓰기 분리 기능 활성화

• 3단계

  • 서비스 제공업체의 mysql 서비스를 클라우드 네이티브 분산 데이터베이스로 대체
  • 읽기 및 쓰기 분리 기능 내장
  • 하위 테이블 내장 기능 켜기

소프트 최적화 - 쿼리 - OLTP

OLTP는 주로 기록에 사용됩니다. 사용자 행동과 같은 특정 유형의 비즈니스 이벤트가 발생하면 시스템은 사용자가 언제, 어디서 무엇을 했는지 기록합니다. )의 데이터가 데이터베이스에 추가, 삭제 및 수정됩니다. 업데이트 처리 작업에는 높은 실시간 성능, 강력한 안정성 및 적시에 성공적인 데이터 업데이트가 필요합니다. 일반적인 비즈니스 시스템은 모두 OLTP이며 사용되는 데이터베이스입니다. MySlq, Oracle 등과 같은 트랜잭션 데이터베이스입니다. OLTP는 쿼리 속도 향상과 서비스 안정성 향상이 최적화의 핵심입니다

• 느린 쿼리
  • 느린 쿼리 로그를 통해 효율성 문제가 있는 SQL 발견
• SQL 문제 해결 방향 문제
  • 인덱스 설계에 문제가 있습니다
  • SQL 문에 문제가 있습니다
  • 잘못된 인덱스가 선택되었습니다. 데이터베이스
  • 단일 테이블이 크다
• 자세한 분석 설명
  • SQL 실행 비율 보기
  • 인덱스 적중 상태 보기(핵심 사항)
• mysql 최적화 프로그램
  • 옵티마이저가 인덱스를 선택하면 인덱스의 카디널리티를 참고하세요
  • 카디널리티는 MySQL 자동으로 유지 및 추정되는 내용이 정확하지 않을 수 있습니다. 인덱스가 맞지 않거나 잘못된 인덱스를 사용하면 분석에 문제가 있어 다시 계산할 수 있습니다. 강제 인덱싱은 인덱스를 강제로 사용하고 비즈니스 코드에 인덱스를 강제로 지정할 수 있습니다
  • 커버드 인덱스 - 가장 이상적인 적중 인덱스
  커버드 인덱스는 동일한 인덱스(고유, 일반, 조인트 인덱스)는 쿼리문 실행부터 반환된 결과까지 사용됩니다.)
• Covered 인덱스는 테이블 쿼리 반환을 줄일 수 있습니다
  • 데이터 쿼리가 두 개 이상의 인덱스를 사용하는 경우 Covering 인덱스가 아닙니다
  할 수 있습니다 SQL 문을 최적화하거나 결합 인덱스를 최적화하여 커버링 인덱스를 사용합니다
• • count() 함수
  • count(비인덱스 필드) - 커버링 인덱스를 사용할 수 없으며 이론적으로 가장 느립니다.
  • count(인덱스 필드) - 커버 가능 인덱스는 여전히 매번 필드가 null인지 확인해야 합니다.
  • count(기본 키) - 위와 동일
  count(1) - 인덱스 트리만 스캔하고 데이터 행을 구문 분석하는 프로세스가 없으며 더 빠릅니다. 이론상으로는 1이 null인지 여부는 여전히 결정됩니다
• count(*) - MySQL은 인덱스를 직접 반환하도록 특별히 count(*) 함수를 최적화했습니다. 트리의 데이터 수, 최적
  • ORDER BY
  • 추가 정렬을 최소화하고 where 조건을 지정합니다.
  • where 문과 ORDER BY 문 조합은 가장 왼쪽 접두사를 충족합니다
  • 가장 효율적입니다. - 인덱스 적용 범위(시나리오 수가 적고 발생할 가능성이 낮음)
  인덱스 적용 범위는 중간 결과 집합 생성을 건너뛸 수 있습니다. 쿼리 결과를 직접 출력합니다
• ORDER 필드는 인덱싱되어야 하며 WHERE 조건 및 출력 내용과 동일한 인덱스에 있어야 합니다
  • Paging Query
    • 먼저 인덱스 적용 범위를 사용할 방법을 찾으세요
    • 먼저 필요한 데이터의 id를 알아내고 테이블로 돌아와서 최종 결과 set
  Index pushdown
• KEY store_id_guide_id (store_id,<code> Guide_id) BTREE
  • select * from table from (1,2) 및guide_id = 3;
  • MySQL5.6 이전에는 인덱스를 사용하여 (1,2)의 store_id를 쿼리해야 합니다. 그런 다음 모든 테이블을 추가하여 film_id = 3
  MySQL5.6인지 확인하세요. 인덱스에서 읽을 수 있으면 직접 인덱스 필터링을 사용하세요
• • loose index scanstore_id_guide_id (store_id,guide_id) USING BTREE
  • select * from table where store_id in (1,2) and guide_id = 3;
  • MySQL5.6之前，需要先拿用索引查询store_id in (1,2),再全部加表验证film_id = 3
  • MySQL5.6之后，如果索引中可以判读，直接使用索引过滤
• 松散索引扫描
  • KEY store_id_guide_id (store_id,guide_id
  KEY store_id_guide_id ( store_id,guide_id) BTREE 사용
  • guide_id = 3
  • MySQL8.0 새 기능
  • 느슨한 인덱스 스캔은 "왼손 원리"를 깨고 문제를 해결할 수 있는 테이블에서 film_id를 선택하세요. 선두 형제를 잃는 문제
  • 공동 인덱스보다 효율성이 낮습니다
• 함수 연산
  • 인덱스 필드에서 함수 연산을 수행하면 옵티마이저가 인덱스를 포기합니다
  • 이 상황에는 다음이 포함될 수 있습니다. 시간 함수, 문자열을 숫자로 변환, 문자 인코딩 변환
  • mysql 함수 대신 서버측 로직 사용을 최적화하세요
• 단일 테이블 크기가 너무 큽니다
  • mysql 소프트웨어마다 다른 단일 테이블 크기를 전달할 수 있습니다. 현재 경험에 따르면 Alibaba Cloud polardb 클러스터 버전에는 2억 개의 단일 테이블이 있을 때 히트 인덱스 쿼리에 문제가 없습니다(우선순위 높음)
  • 데이터 정산 - 예를 들어 파이프라인 데이터는 다음과 같이 정산할 수 있습니다. 특정 시점에 최신 값을 얻고 확정된 파이프라인 전송 백업 테이블로 이동(중간 우선순위)
  • 핫 데이터와 콜드 데이터 분리 - 정산할 수 없는 데이터는 쿼리 빈도에 따라 구분, 낮음 빈도 데이터는 쿼리를 위해 다른 테이블로 전송되며, 쿼리 항목은 비즈니스 측면에서 구별됩니다(중간 우선순위)
  • 분산 데이터베이스 테이블 분할 - 주문이 있는 분산 데이터베이스의 테이블 분할 기능과 분산 데이터베이스의 테이블 분할 기능이 가능합니다. 구성 요소는 테이블 분할 후 삽입 및 쿼리를 관리합니다(중간 우선 순위)
  • 코드 구현 테이블 분할 - 특정 규칙에 따라 단일 테이블을 여러 테이블로 분할하려면 PHP 및 GO의 대부분의 프레임워크 ORM에서 분할한 후 프레임워크 ORM에 대한 특정 수정이 필요합니다. JAVA의 ORM은 기본적으로 지원되며, 나중에는 난이도가 높을수록(낮은 우선순위)

소프트 최적화 - 쓰기 업데이트 삭제

• Lock

  • MySQL 잠금은 세분화에 따라 전역 잠금, 테이블 수준 잠금, 행 잠금

  • 전역 잠금
    • self-google/baidu

  • table-으로 나눌 수 있습니다. 레벨 잠금은 테이블 잠금(데이터 잠금)과 메타데이터 잠금으로 구분됩니다.
    • 테이블 잠금
      • self-google/baidu
    • 메타데이터 잠금
      • Self-google/baidu

  • 행 잠금이 잠깁니다. 공유 잠금과 독점 잠금으로 구분되는 데이터 행
    • Self-google/baidu

• 교착 상태에 대한 솔루션🎜
  • 매개변수 구성
    • innodb_lock_wait_timeout 매개변수를 조정하세요
      • 기본값은 50초입니다. 즉, 50초 동안 기다린 후에도 잠금이 획득되지 않으면 현재 문에서 오류를 보고합니다
      • 대기 시간이 너무 길면, 이 매개변수를 적절하게 단축할 수 있습니다
    • 활성 교착 상태 감지: innodb_deadlock_Detect
      • 교착 상태가 발견되면 비용이 덜 드는 트랜잭션을 롤백합니다.
      • 기본적으로 활성화됨
  • 불필요할 때 트랜잭션을 열지 마세요
  • 쿼리는 다음과 같아야 합니다. 잠긴 행 수를 줄이기 위해 최대한 트랜잭션 외부에 배치
  • 트랜잭션 시간을 피하세요. 너무 길면 트랜잭션에서 http 요청을 트리거하지 마세요
  • 트랜잭션 상태를 사전에 확인하세요

    show  processlist;SELECT * FROM information_schema.INNODB_TRX; //长事务SELECT * FROM information_schema.INNODB_LOCKs; //查看锁SELECT * FROM information_schema.INNODB_LOCK_waits; //查看阻塞事务

비즈니스 검색

• The 검색 행 수가 100,000개 미만 - mysql은 휴대하기 어렵습니다
  • mysql의 CPU, IO, 메모리 하드웨어 개선
• 100,000개 이상의 검색 행 - Elasticsearch 소개

Elasticsearch의 반전 인덱스 소개 전체 텍스트 검색이 가능하지만 데이터 구조의 유연성이 낮습니다.

• 데이터 동기화
  • 비즈니스 코드에서 데이터가 변경되면 동시에 Elasticsearch에 동기화됩니다.
  • mysql 로그 구독을 취소하면 동기화가 트리거됩니다.
• Elasticsearch-index
  • 는 동일한 필드를 가진 문서 목록으로 구성됩니다. - mysql의 테이블
  • 필드와 유사합니다. 유형이 설정되면 수정이 금지되고 새 필드가 허용됩니다.
  • 구체적인 방법은 google/baidu
• Elasticsearch-Document
  • 사용자가 저장한 데이터 문서입니다. es - mysql
  • 메타데이터 및 Json 객체 구성에 따른 행과 유사
  • 메타데이터 및 Json 객체 세부정보 self-google/baidu
• Elasticsearch-word Segmenter
  • self-google/baidu
• Elasticsearch-inverted index(key)
  • self-google/baidu
• Elasticsearch-Aggregation Analysis
  • Automatic google/baidu

Statistical Business-OLAP

OLAP은 데이터에 대한 의사결정 분석에 사용됩니다. OLTP 트랜잭션 처리 시나리오입니다. 빅데이터 분석의 응용 프로그램입니다. 위에서 언급한 오프라인 데이터 웨어하우스 아이디어는 특정 기술 스택이 아닙니다. OLAP 분석 및 처리 아이디어를 반영할 수 있는 솔루션은 OLAP입니다.

초기 데이터 웨어하우스 구축은 주로 의사결정 분석 요구 사항에 따라 ERP, CRM, SCM 및 기타 데이터와 같은 기업 비즈니스 데이터베이스를 모델링하고 데이터 웨어하우스 엔진에 요약하는 것을 의미합니다. 그 적용은 주로 보고서를 기반으로 합니다. 경영진 및 사업 인력의 의사 결정을 지원하는 목적(중장기 전략 결정) IT 기술이 인터넷과 모빌리티로 발전함에 따라 데이터 소스는 점점 더 풍부해지고 있습니다. 웹 사이트 로그, IoT 장치 데이터, APP 매장 데이터 등 원래 비즈니스 데이터베이스를 기반으로 비정형 데이터가 나타납니다. 이는 이전의 구조화된 데이터보다 몇 배 더 큽니다.

OLAP이 직면한 비즈니스가 어떻게 변화하더라도 분석 분야 결정 -> 비즈니스 데이터를 컴퓨팅 라이브러리에 동기화 -> 데이터 정리 모델링 -> 데이터 웨어하우스와 동기화 -> 단계는 불가분의 관계에 있습니다. ;외부에 노출

계산 소스 데이터베이스는 데이터 정리를 위해 특별히 사용되며, 그 목적은 데이터 정리 중에 비즈니스 데이터베이스의 성능에 영향을 미치지 않도록 하는 것입니다. 계산원본 데이터베이스의 데이터를 업무별, 차원별로 정리하여 데이터의 활용성과 재사용성을 높이고, 최종 실시간 상세 데이터를 획득하여 데이터 웨어하우스로 전송하고, 데이터 웨어하우스에서 제공하는 서비스 최종 의사결정 분석 데이터.

DEMO 계획

생산 계획

각 링크의 소프트웨어는 동일한 기능을 가진 소프트웨어로 대체 가능합니다. 팀이 소프트웨어 구현 계획에 대해 가장 자신 있는 경우 계획은 OLAP입니다.

요약

최적화는 단계별로 역량을 축적하고 여러 차례의 반복을 통해 현실적으로 이루어져야 하며 하루아침에 달성할 수는 없습니다. 자신의 기반, 비즈니스 시나리오 및 향후 개발 기대치를 기반으로 여러 라운드의 반복을 수행합니다.

반복의 원칙은 먼저 소프트 최적화와 하드 최적화를 통해 단일 소프트웨어 서비스의 효율성을 높이는 것입니다. 향후 개발 기대치를 기준으로 최적화 비용이 수익보다 낮을 때 시장에 나와 있는 성숙한 솔루션을 참조하여 도입합니다. 결합된 혁신을 위해 새로운 소프트웨어를 사용할 때, 유기적인 통합을 통해서만 참조된 소프트웨어가 만나면 1+1>2, 2+1>3의 효과를 얻을 수 있습니다. 병목 현상이 발생하면 이 과정을 반복하세요.

위의 내용은 모두 기사의 내용입니다. 내용에서 제안한 최적화 포인트와 솔루션은 반드시 개인적인 작업의 모범 사례는 아닙니다. 토론하고 교환하는 것을 환영합니다. ㅋㅋㅋ

위 내용은 매우 좋아하는 공유: 프로덕션에 부합하는 MySQL 최적화 아이디어의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!