itsource

MariaDB - 테이블에 인덱스를 추가해야 합니까?

mycopycode 2022. 9. 5. 23:17
반응형

MariaDB - 테이블에 인덱스를 추가해야 합니까?

최근에 시스템 로그를 확인했는데 일부 쿼리가 매우 느리다는 것을 발견했습니다.

사용자 액티비티를 저장하는 테이블이 있습니다.테이블 구조는id (int), user (int), type (int), object (varchar), extra (mediumtext) and date (timestamp).

또한 나는 오직 의 색인만 가지고 있다.id (BTREE, unique).

다음 쿼리에 대한 성능 문제가 있습니다.

SELECT  DISTINCT object as usrobj
    from  ".MV15_PREFIX."useractivities
    WHERE  user='".$user_id."'
      and  type = '3'
    limit  0,1000000" 

문제는, 내가 또한 색인화해야 하는가이다.user와 같은id어떤 방법을 따라야 합니까?

이 테이블은 현재 사용되고 있으며 500k 이상의 행이 있습니다.또한 사이트에는 동시접속자가 평균 2k~건 있습니다.

제가 이 질문을 하는 이유는 DB를 잘 관리하지 못하기 때문이며, 또한 인덱스가 적절한 다른 테이블에서 느린 쿼리 문제가 발생하고 있기 때문입니다.

제안해 주셔서 감사합니다.

사이드 노트:

mysqltuner 결과

일반적인 권장 사항:

Reduce or eliminate persistent connections to reduce connection usage
Adjust your join queries to always utilize indexes
Temporary table size is already large - reduce result set size
Reduce your SELECT DISTINCT queries without LIMIT clauses
Consider installing Sys schema from https://github.com/mysql/mysql-sys

조정할 변수:

max_connections (> 768)
wait_timeout (< 28800)
interactive_timeout (< 28800)
join_buffer_size (> 64.0M, or always use indexes with joins)

(설정하겠습니다.max_connections> 768, 타임아웃에 대해서는 잘 모릅니다.지금까지 Stackoverflow에서 토픽/제안 내용을 읽고 있는 한, 그 크기를 늘려서는 안 된다고 생각합니다.join_buffer_size하지만 이 변수들에 대한 피드백도 주시면 감사하겠습니다.)

EDIT - 인덱스 결과 표시

+--------------------+------------+-----------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| Table              | Non_unique | Key_name        | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment |
+--------------------+------------+-----------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| ***_useractivities |          0 | PRIMARY         |            1 | id          | A         |      434006 |     NULL | NULL   |      | BTREE      |         |               |
| ***_useractivities |          1 | user_index      |            1 | user        | A         |       13151 |     NULL | NULL   |      | BTREE      |         |               |
| ***_useractivities |          1 | user_type_index |            1 | user        | A         |       10585 |     NULL | NULL   |      | BTREE      |         |               |
| ***_useractivities |          1 | user_type_index |            2 | type        | A         |       13562 |     NULL | NULL   |      | BTREE      |         |               |
+--------------------+------------+-----------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+

Postgre에 대한 대부분의 경험적 규칙SQL 인덱스는 대부분의 SQL 데이터베이스 관리 시스템에 적용됩니다.

https://dba.stackexchange.com/a/31517/1064

그래서, 당신은 아마도 다음 지수의 혜택을 받을 것입니다.user및 에 대한 색인type. 쌍에 대한 인덱스를 통해 더 많은 이점을 얻을 수 있습니다.user, type.

실행 계획을 읽는 방법도 배울 수 있습니다.

이 쿼리에 대해서는 다음 중 하나가 최적입니다.

INDEX(user, type)
INDEX(type, user)

개별 인덱스(INDEX(user), INDEX(type))는 그다지 좋지 않을 가능성이 있습니다.

MySQL의 InnoDB에는BTree,것은 아니다.Hash어쨌든 BTree는 기본적으로 '포인트 쿼리'에 대해서는 해시만큼 우수하며 '범위' 쿼리에 대해서는 매우 우수합니다.

인덱싱 힌트

인덱스 도움말SELECTs그리고.UPDATEs, 때때로 많이.그것들을 사용하세요.여분의 디스크 공간을 사용하는 등 부작용이 미미합니다.

언급URL : https://stackoverflow.com/questions/50216991/mariadb-should-i-add-index-to-my-table

반응형