MariaDB 10.2.22 Galera Cluster Using Bad Indexes After AnalyzeInnoDB - Use combined index with primary key on...
How to transport 10,000 terrestrial trolls across ocean fast?
What sort of grammatical construct is ‘Quod per sortem sternit fortem’?
What is the reward?
Can someone explain what a key is?
bash aliases do not expand even with shopt expand_aliases
Does しかたない imply disappointment?
Can someone explain European graduate programs in STEM fields?
Coworker is trying to get me to sign his petition to run for office. How to decline politely?
How do I purchase a drop bar bike that will be converted to flat bar?
Can a Way of Shadow Monk use Shadow Step to teleport to a dark ceiling and then body slam another creature?
Is there any danger of my neighbor having my wife's signature?
Are all power cords made equal?
Why don't programs completely uninstall (remove all their files) when I remove them?
Is there redundancy between a US Passport Card and an Enhanced Driver's License?
Missing a connection and don't have money to book next flight
What does @ mean in a hostname in DNS configuration?
Have any astronauts or cosmonauts died in space?
Crack the bank account's password!
What is an explicit bijection in combinatorics?
Abstract algebra subgroup proof verification
Including proofs of known theorems in master's thesis
Why would you use 2 alternate layout buttons instead of 1, when only one can be selected at once
Is there a way to pause a running process on Linux systems and resume later?
How can changes in personality/values of a person who turned into a vampire be explained?
MariaDB 10.2.22 Galera Cluster Using Bad Indexes After Analyze
InnoDB - Use combined index with primary key on GROUP BYAwful execution plans after migrating from MySQL 5.5.11 to MariaDB 5.5.41MariaDB Galera Cluster ReplicationHow can I improve this table, and subsequently the performance of the queries I execute on it?If I query records matching some value, why does InnoDB examine most of the records that had that value once, but have changed since then?Index not used on partitioned tablemariadb galera bootstrapping failsslow queries on indexed columns (large datasets)MariaDB Galera Cluster - Cert Deps Distance issueMariaDB Galera Cluster - first node won't reconnect after restart… Ever
I'm using Drupal on a MariaDB Galera 10.2.22 3 node cluster and I'm having some problems with one query. I have a table (InnoDB) called field_data_field_department which has a bunch of indexes. If I dump the 5 tables used in my query and load them into a new DB, the query runs fine using the index field_department_target_id. But once I analyze that table (or MariaDB does an internal stats rebuild) the query stops using that index and uses the PRIMARY index. I don't understand why it does this, and the query is MUCH slower using PRIMARY (90-120 seconds vs under 1/10th of a second.)
Does anyone know how I can diagnose why the planner is picking the wrong index? Or why ANALYZEing the table makes it break (I would think that would make things better) The query is dynamically generated by Drupal so I can't just go into the code and add FORCE INDEX.
Here's the explain for the fast result:
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE file_managed ref uri,status,file_type status 1 const 7403 Using where; Using temporary; Using filesort
1 SIMPLE field_data_field_department ref PRIMARY,entity_type,deleted,entity_id PRIMARY 391 const,drupal_authoring.file_managed.fid,const 1 Using where
1 SIMPLE taxonomy_term_data_field_data_field_department eq_ref PRIMARY PRIMARY 4 drupal_authoring.field_data_field_department.field_department_target_id 1 Using where; Using index
1 SIMPLE taxonomy_term_data_field_data_field_department__field_data_field_department ref PRIMARY,entity_type,deleted,field_department_target_id field_department_target_id 390 drupal_authoring.taxonomy_term_data_field_data_field_department.tid,const 15 Using where; Using index
1 SIMPLE file_usage ref PRIMARY,fid_count,fid_module fid_count 4 drupal_authoring.file_managed.fid 1 Using index
And for the slow query:
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE file_managed ref uri,status,file_type file_type 152 const 7592 Using index condition; Using where; Using temporary; Using filesort
1 SIMPLE field_data_field_department ref PRIMARY,entity_type,deleted,entity_id PRIMARY 391 const,drupal_authoring.file_managed.fid,const 1 Using where
1 SIMPLE taxonomy_term_data_field_data_field_department eq_ref PRIMARY PRIMARY 4 drupal_authoring.field_data_field_department.field_department_target_id 1 Using where; Using index
1 SIMPLE taxonomy_term_data_field_data_field_department__field_data_field_department ref PRIMARY,entity_type,deleted,field_department_target_id PRIMARY 386 const 7985 Using where
1 SIMPLE file_usage ref PRIMARY,fid_count,fid_module fid_count 4 drupal_authoring.file_managed.fid 1 Using index
And here is the output of SHOW INDEXES
Table Non_unique Key_name Seq_in_index Column_name Collation Cardinality Sub_part Packed Null Index_type Comment Index_comment
field_data_field_department 0 PRIMARY 1 entity_type A 4 NULL NULL BTREE
field_data_field_department 0 PRIMARY 2 entity_id A 15742 NULL NULL BTREE
field_data_field_department 0 PRIMARY 3 deleted A 15742 NULL NULL BTREE
field_data_field_department 0 PRIMARY 4 delta A 15742 NULL NULL BTREE
field_data_field_department 0 PRIMARY 5 language A 15742 NULL NULL BTREE
field_data_field_department 1 entity_type 1 entity_type A 4 NULL NULL BTREE
field_data_field_department 1 bundle 1 bundle A 24 NULL NULL BTREE
field_data_field_department 1 deleted 1 deleted A 2 NULL NULL BTREE
field_data_field_department 1 entity_id 1 entity_id A 15742 NULL NULL BTREE
field_data_field_department 1 revision_id 1 revision_id A 15742 NULL NULL YES BTREE
field_data_field_department 1 language 1 language A 2 NULL NULL BTREE
field_data_field_department 1 field_department_target_id 1 field_department_target_id A 715 NULL NULL BTREE
Any ideas? Even if I can just do something to stop MariaDB from analyzing the table that would help. I can dump and reload it as a temp fix, but that only lasts for a little while.
index mariadb galera mariadb-10.2
New contributor
add a comment |
I'm using Drupal on a MariaDB Galera 10.2.22 3 node cluster and I'm having some problems with one query. I have a table (InnoDB) called field_data_field_department which has a bunch of indexes. If I dump the 5 tables used in my query and load them into a new DB, the query runs fine using the index field_department_target_id. But once I analyze that table (or MariaDB does an internal stats rebuild) the query stops using that index and uses the PRIMARY index. I don't understand why it does this, and the query is MUCH slower using PRIMARY (90-120 seconds vs under 1/10th of a second.)
Does anyone know how I can diagnose why the planner is picking the wrong index? Or why ANALYZEing the table makes it break (I would think that would make things better) The query is dynamically generated by Drupal so I can't just go into the code and add FORCE INDEX.
Here's the explain for the fast result:
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE file_managed ref uri,status,file_type status 1 const 7403 Using where; Using temporary; Using filesort
1 SIMPLE field_data_field_department ref PRIMARY,entity_type,deleted,entity_id PRIMARY 391 const,drupal_authoring.file_managed.fid,const 1 Using where
1 SIMPLE taxonomy_term_data_field_data_field_department eq_ref PRIMARY PRIMARY 4 drupal_authoring.field_data_field_department.field_department_target_id 1 Using where; Using index
1 SIMPLE taxonomy_term_data_field_data_field_department__field_data_field_department ref PRIMARY,entity_type,deleted,field_department_target_id field_department_target_id 390 drupal_authoring.taxonomy_term_data_field_data_field_department.tid,const 15 Using where; Using index
1 SIMPLE file_usage ref PRIMARY,fid_count,fid_module fid_count 4 drupal_authoring.file_managed.fid 1 Using index
And for the slow query:
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE file_managed ref uri,status,file_type file_type 152 const 7592 Using index condition; Using where; Using temporary; Using filesort
1 SIMPLE field_data_field_department ref PRIMARY,entity_type,deleted,entity_id PRIMARY 391 const,drupal_authoring.file_managed.fid,const 1 Using where
1 SIMPLE taxonomy_term_data_field_data_field_department eq_ref PRIMARY PRIMARY 4 drupal_authoring.field_data_field_department.field_department_target_id 1 Using where; Using index
1 SIMPLE taxonomy_term_data_field_data_field_department__field_data_field_department ref PRIMARY,entity_type,deleted,field_department_target_id PRIMARY 386 const 7985 Using where
1 SIMPLE file_usage ref PRIMARY,fid_count,fid_module fid_count 4 drupal_authoring.file_managed.fid 1 Using index
And here is the output of SHOW INDEXES
Table Non_unique Key_name Seq_in_index Column_name Collation Cardinality Sub_part Packed Null Index_type Comment Index_comment
field_data_field_department 0 PRIMARY 1 entity_type A 4 NULL NULL BTREE
field_data_field_department 0 PRIMARY 2 entity_id A 15742 NULL NULL BTREE
field_data_field_department 0 PRIMARY 3 deleted A 15742 NULL NULL BTREE
field_data_field_department 0 PRIMARY 4 delta A 15742 NULL NULL BTREE
field_data_field_department 0 PRIMARY 5 language A 15742 NULL NULL BTREE
field_data_field_department 1 entity_type 1 entity_type A 4 NULL NULL BTREE
field_data_field_department 1 bundle 1 bundle A 24 NULL NULL BTREE
field_data_field_department 1 deleted 1 deleted A 2 NULL NULL BTREE
field_data_field_department 1 entity_id 1 entity_id A 15742 NULL NULL BTREE
field_data_field_department 1 revision_id 1 revision_id A 15742 NULL NULL YES BTREE
field_data_field_department 1 language 1 language A 2 NULL NULL BTREE
field_data_field_department 1 field_department_target_id 1 field_department_target_id A 715 NULL NULL BTREE
Any ideas? Even if I can just do something to stop MariaDB from analyzing the table that would help. I can dump and reload it as a temp fix, but that only lasts for a little while.
index mariadb galera mariadb-10.2
New contributor
add a comment |
I'm using Drupal on a MariaDB Galera 10.2.22 3 node cluster and I'm having some problems with one query. I have a table (InnoDB) called field_data_field_department which has a bunch of indexes. If I dump the 5 tables used in my query and load them into a new DB, the query runs fine using the index field_department_target_id. But once I analyze that table (or MariaDB does an internal stats rebuild) the query stops using that index and uses the PRIMARY index. I don't understand why it does this, and the query is MUCH slower using PRIMARY (90-120 seconds vs under 1/10th of a second.)
Does anyone know how I can diagnose why the planner is picking the wrong index? Or why ANALYZEing the table makes it break (I would think that would make things better) The query is dynamically generated by Drupal so I can't just go into the code and add FORCE INDEX.
Here's the explain for the fast result:
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE file_managed ref uri,status,file_type status 1 const 7403 Using where; Using temporary; Using filesort
1 SIMPLE field_data_field_department ref PRIMARY,entity_type,deleted,entity_id PRIMARY 391 const,drupal_authoring.file_managed.fid,const 1 Using where
1 SIMPLE taxonomy_term_data_field_data_field_department eq_ref PRIMARY PRIMARY 4 drupal_authoring.field_data_field_department.field_department_target_id 1 Using where; Using index
1 SIMPLE taxonomy_term_data_field_data_field_department__field_data_field_department ref PRIMARY,entity_type,deleted,field_department_target_id field_department_target_id 390 drupal_authoring.taxonomy_term_data_field_data_field_department.tid,const 15 Using where; Using index
1 SIMPLE file_usage ref PRIMARY,fid_count,fid_module fid_count 4 drupal_authoring.file_managed.fid 1 Using index
And for the slow query:
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE file_managed ref uri,status,file_type file_type 152 const 7592 Using index condition; Using where; Using temporary; Using filesort
1 SIMPLE field_data_field_department ref PRIMARY,entity_type,deleted,entity_id PRIMARY 391 const,drupal_authoring.file_managed.fid,const 1 Using where
1 SIMPLE taxonomy_term_data_field_data_field_department eq_ref PRIMARY PRIMARY 4 drupal_authoring.field_data_field_department.field_department_target_id 1 Using where; Using index
1 SIMPLE taxonomy_term_data_field_data_field_department__field_data_field_department ref PRIMARY,entity_type,deleted,field_department_target_id PRIMARY 386 const 7985 Using where
1 SIMPLE file_usage ref PRIMARY,fid_count,fid_module fid_count 4 drupal_authoring.file_managed.fid 1 Using index
And here is the output of SHOW INDEXES
Table Non_unique Key_name Seq_in_index Column_name Collation Cardinality Sub_part Packed Null Index_type Comment Index_comment
field_data_field_department 0 PRIMARY 1 entity_type A 4 NULL NULL BTREE
field_data_field_department 0 PRIMARY 2 entity_id A 15742 NULL NULL BTREE
field_data_field_department 0 PRIMARY 3 deleted A 15742 NULL NULL BTREE
field_data_field_department 0 PRIMARY 4 delta A 15742 NULL NULL BTREE
field_data_field_department 0 PRIMARY 5 language A 15742 NULL NULL BTREE
field_data_field_department 1 entity_type 1 entity_type A 4 NULL NULL BTREE
field_data_field_department 1 bundle 1 bundle A 24 NULL NULL BTREE
field_data_field_department 1 deleted 1 deleted A 2 NULL NULL BTREE
field_data_field_department 1 entity_id 1 entity_id A 15742 NULL NULL BTREE
field_data_field_department 1 revision_id 1 revision_id A 15742 NULL NULL YES BTREE
field_data_field_department 1 language 1 language A 2 NULL NULL BTREE
field_data_field_department 1 field_department_target_id 1 field_department_target_id A 715 NULL NULL BTREE
Any ideas? Even if I can just do something to stop MariaDB from analyzing the table that would help. I can dump and reload it as a temp fix, but that only lasts for a little while.
index mariadb galera mariadb-10.2
New contributor
I'm using Drupal on a MariaDB Galera 10.2.22 3 node cluster and I'm having some problems with one query. I have a table (InnoDB) called field_data_field_department which has a bunch of indexes. If I dump the 5 tables used in my query and load them into a new DB, the query runs fine using the index field_department_target_id. But once I analyze that table (or MariaDB does an internal stats rebuild) the query stops using that index and uses the PRIMARY index. I don't understand why it does this, and the query is MUCH slower using PRIMARY (90-120 seconds vs under 1/10th of a second.)
Does anyone know how I can diagnose why the planner is picking the wrong index? Or why ANALYZEing the table makes it break (I would think that would make things better) The query is dynamically generated by Drupal so I can't just go into the code and add FORCE INDEX.
Here's the explain for the fast result:
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE file_managed ref uri,status,file_type status 1 const 7403 Using where; Using temporary; Using filesort
1 SIMPLE field_data_field_department ref PRIMARY,entity_type,deleted,entity_id PRIMARY 391 const,drupal_authoring.file_managed.fid,const 1 Using where
1 SIMPLE taxonomy_term_data_field_data_field_department eq_ref PRIMARY PRIMARY 4 drupal_authoring.field_data_field_department.field_department_target_id 1 Using where; Using index
1 SIMPLE taxonomy_term_data_field_data_field_department__field_data_field_department ref PRIMARY,entity_type,deleted,field_department_target_id field_department_target_id 390 drupal_authoring.taxonomy_term_data_field_data_field_department.tid,const 15 Using where; Using index
1 SIMPLE file_usage ref PRIMARY,fid_count,fid_module fid_count 4 drupal_authoring.file_managed.fid 1 Using index
And for the slow query:
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE file_managed ref uri,status,file_type file_type 152 const 7592 Using index condition; Using where; Using temporary; Using filesort
1 SIMPLE field_data_field_department ref PRIMARY,entity_type,deleted,entity_id PRIMARY 391 const,drupal_authoring.file_managed.fid,const 1 Using where
1 SIMPLE taxonomy_term_data_field_data_field_department eq_ref PRIMARY PRIMARY 4 drupal_authoring.field_data_field_department.field_department_target_id 1 Using where; Using index
1 SIMPLE taxonomy_term_data_field_data_field_department__field_data_field_department ref PRIMARY,entity_type,deleted,field_department_target_id PRIMARY 386 const 7985 Using where
1 SIMPLE file_usage ref PRIMARY,fid_count,fid_module fid_count 4 drupal_authoring.file_managed.fid 1 Using index
And here is the output of SHOW INDEXES
Table Non_unique Key_name Seq_in_index Column_name Collation Cardinality Sub_part Packed Null Index_type Comment Index_comment
field_data_field_department 0 PRIMARY 1 entity_type A 4 NULL NULL BTREE
field_data_field_department 0 PRIMARY 2 entity_id A 15742 NULL NULL BTREE
field_data_field_department 0 PRIMARY 3 deleted A 15742 NULL NULL BTREE
field_data_field_department 0 PRIMARY 4 delta A 15742 NULL NULL BTREE
field_data_field_department 0 PRIMARY 5 language A 15742 NULL NULL BTREE
field_data_field_department 1 entity_type 1 entity_type A 4 NULL NULL BTREE
field_data_field_department 1 bundle 1 bundle A 24 NULL NULL BTREE
field_data_field_department 1 deleted 1 deleted A 2 NULL NULL BTREE
field_data_field_department 1 entity_id 1 entity_id A 15742 NULL NULL BTREE
field_data_field_department 1 revision_id 1 revision_id A 15742 NULL NULL YES BTREE
field_data_field_department 1 language 1 language A 2 NULL NULL BTREE
field_data_field_department 1 field_department_target_id 1 field_department_target_id A 715 NULL NULL BTREE
Any ideas? Even if I can just do something to stop MariaDB from analyzing the table that would help. I can dump and reload it as a temp fix, but that only lasts for a little while.
index mariadb galera mariadb-10.2
index mariadb galera mariadb-10.2
New contributor
New contributor
New contributor
asked 7 mins ago
Charles TassellCharles Tassell
1
1
New contributor
New contributor
add a comment |
add a comment |
0
active
oldest
votes
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "182"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Charles Tassell is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fdba.stackexchange.com%2fquestions%2f230535%2fmariadb-10-2-22-galera-cluster-using-bad-indexes-after-analyze%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
0
active
oldest
votes
0
active
oldest
votes
active
oldest
votes
active
oldest
votes
Charles Tassell is a new contributor. Be nice, and check out our Code of Conduct.
Charles Tassell is a new contributor. Be nice, and check out our Code of Conduct.
Charles Tassell is a new contributor. Be nice, and check out our Code of Conduct.
Charles Tassell is a new contributor. Be nice, and check out our Code of Conduct.
Thanks for contributing an answer to Database Administrators Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fdba.stackexchange.com%2fquestions%2f230535%2fmariadb-10-2-22-galera-cluster-using-bad-indexes-after-analyze%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown