Как MySQL использует сопоставления с индексами?
<button class="btn btn-sm btn-danger delete-article-btn mybtn-{{$article['aID']}}"
rel="{{ $article['aID'] }}" rel2="1">Active
</button>
<script>
$(document).on('click','.delete-article-btn',function(){
var id = $(this).attr('rel');
var status = $(this).attr('rel2');
$.ajax({
url: '{!! URL('/pay/dash/panel/delete_article') !!}',
type: 'post',
dataType: 'json',
data: {'user_id': id,'status':status},
success: function (response) {
console.log(response);
console.log('Article ID',id);
if (response == 1) {
$('.mybtn-'+id).html('Inactive');
$('.mybtn-'+id).attr('rel2',0);
} else {
$('.mybtn-'+id).html('Active');
$('.mybtn-'+id).attr('rel2',1);
}
}, error: function (error) {
}
});
})
</script>
public function deleteArticles(Request $request)
{
$userId = $request->input('user_id');
$status = $request->input('status');
$result = 0;
if ($status==0) {
Article::where('id', $userId)->update(['is_deleted' => 1]);
$result = 1;
} else {
Article::where('id', $userId)->update(['is_deleted' => 0]);
$result = 0;
}
return $result;
}
2 ответа
Я полагаю, что структура B-дерева будет отличаться, потому что она должна сравнить значения столбцов по-другому.
Взгляд на эти два плана запросов:
mysql> explain select * from sometable where keycol = '3';
+----+-------------+-------+------+---------------+---------+---------+-------+------+--------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+------+---------------+---------+---------+-------+------+--------------------------+
| 1 | SIMPLE | pro | ref | PRIMARY | PRIMARY | 66 | const | 34 | Using where; Using index |
+----+-------------+-------+------+---------------+---------+---------+-------+------+--------------------------+
mysql> explain select * from sometable where binary keycol = '3';
+----+-------------+-------+-------+---------------+---------+---------+------+-------+--------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+-------+---------------+---------+---------+------+-------+--------------------------+
| 1 | SIMPLE | pro | index | NULL | PRIMARY | 132 | NULL | 14417 | Using where; Using index |
+----+-------------+-------+-------+---------------+---------+---------+------+-------+--------------------------+
Если мы изменяем сопоставление для сравнения, внезапно оно даже не может искать индекс больше и должно просканировать каждую строку. Фактические значения, сохраненные в индексе, будут тем же независимо от сопоставления, например, потому что это все еще возвратит значение в своем исходном преобразовании регистра независимо от того, использует ли это чувствительное к регистру или нечувствительное к регистру сопоставление.
Таким образом, поиски против нечувствительного к регистру сопоставления должны быть немного менее эффективными.
Однако я сомневаюсь, что Вы когда-либо могли бы заметить различие; обратите внимание, что MySQL делает все нечувствительным к регистру по умолчанию, таким образом, влияние не может быть настолько ужасным.
ОБНОВЛЕНИЕ:
Вы видите подобный эффект для порядка операциями:
mysql> explain select * from sometable order by keycol collate latin1_general_cs;
+----+-------------+-------+-------+---------------+---------+---------+------+-------+-----------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+-------+---------------+---------+---------+------+-------+-----------------------------+
| 1 | SIMPLE | pro | index | NULL | PRIMARY | 132 | NULL | 14417 | Using index; Using filesort |
+----+-------------+-------+-------+---------------+---------+---------+------+-------+-----------------------------+
mysql> explain select * from sometable order by keycol ;
+----+-------------+-------+-------+---------------+---------+---------+------+-------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+-------+---------------+---------+---------+------+-------+-------------+
| 1 | SIMPLE | pro | index | NULL | PRIMARY | 132 | NULL | 14417 | Using index |
+----+-------------+-------+-------+---------------+---------+---------+------+-------+-------------+
Отметьте дополнительный этап 'filesort', требуемый выполнить запрос. Это означает, что mysql стоит в очереди результат во временном буфере и сортирует его сам использование quicksort на дополнительном этапе, выводя независимо от того, что индексный порядок был. Используя исходное сопоставление этот шаг является uneccessary, поскольку mysql знает порядок от индекса первоначально.
MySQL будет использовать сопоставление столбца для индекса. Таким образом, при создании utf8_unicode_ci поля затем индекс также будет в порядке utf8_unicode_ci эффективно.
Следует иметь в виду, что использование индекса будет не всегда 100% обходить влияние производительности, но для наиболее практических целей это будет.
Много систем баз данных не являются зависящими от ЦП, таким образом, я сомневаюсь, что Вы заметили бы влияние.