I haciendo índices a la tabla con millones de registros que se utilizan para buscar resultados. Estoy mostrando los resultados por orden ASC o DESC. Mi pregunta es si la columna debe tener índice o no? Tengo 2 índices más en esa tabla. ¿Cómo afectará el rendimiento haciendo o no indexando esa columna?¿El orden por columna debe tener índice o no?
El orden por columnas se usa para ordenar el conjunto de resultados, no para filtrar. Es poco probable que un índice en las columnas mencionadas en la cláusula order by cambie algo, especialmente si no se usa para filtrar los datos.
: Esa columna se usará también en las condiciones. Entonces, ¿cómo afectará la complejidad del tiempo de la consulta de búsqueda? –
Agregar un índice debería reducir el tiempo. Sin mirar los planes de ejecución de la consulta o la consulta, no hay forma de saberlo. – Sathya
Ok. Voy a verificar los planes de ejecución de consultas a continuación. Gracias. –
En realidad, para algunas filas de millones es mejor aplicar algún índice bien pensado, no es un conjunto de datos tan grande para empezar a preocuparse por problemas de rendimiento espacial.
pero
Si usted lee la mesa una vez al día y actualizar/eliminar filas 100 veces por segundo - a continuación, el efecto del índice puede degradar el rendimiento de las operaciones principales, mientras que la selección de occasinally se obtienen mejores resultados.
Por lo tanto, la respuesta como de costumbre - depende
Es la lógica del filtro de búsqueda. Entonces, la tabla se leerá 10000 veces más de lo que se escriba. ¿Que debería hacer? –
Definitivamente tiene un buen índice - es su caso –
El uso de ORDER BY en la columna indexada no es una buena idea. En realidad, el propósito de usar el índice es hacer que la búsqueda sea más rápida para que la columna de índice ayude a mantener los datos en orden ordenado. Sugeriré que use ORDER BY en la columna no indexada. Ejecuté una consulta de muestra en MySql y obtuve el resultado que se menciona a continuación.
SELECT
ci.id AS item_id, ci.brand_id, ci.category_id,
ci.item_size_type, ci.is_express_processing, ci.packing,
ci.parent_service_id, ci.product_id, ci.size,
ci.create_date AS item_create_date, cis.service_id, cis.quantity
FROM
cart AS c
INNER JOIN
cart_items AS ci ON ci.cart_id = c.id
LEFT JOIN
cart_item_services AS cis ON cis.item_id = ci.id
WHERE
c.id = 144
ORDER BY
c.create_date;
Aquí estoy usando ORDER BY en una columna no indexada create_date y el resultado es el siguiente:
# Time: 2017-11-03T10:30:33.237056Z
# [email protected]: root[root] @ localhost [] Id: 3
# Query_time: 0.000340
# Lock_time: 0.000154 Rows_sent: 2 Rows_examined: 4
Y ahora voy a utilizar ORDER BY en una columna indexada item_id:
SELECT
ci.id AS item_id, ci.brand_id, ci.category_id,
ci.item_size_type, ci.is_express_processing, ci.packing,
ci.parent_service_id, ci.product_id, ci.size,
ci.create_date AS item_create_date, cis.service_id, cis.quantity
FROM
cart AS c
INNER JOIN
cart_items AS ci ON ci.cart_id = c.id
LEFT JOIN
cart_item_services AS cis ON cis.item_id = ci.id
WHERE
c.id = 144
ORDER BY
item_id;
Ahora tengo el resultado de la siguiente manera.
# Time: 2017-11-03T10:30:47.802392Z
# [email protected]: root[root] @ localhost [] Id: 3
# Query_time: 0.000383
# Lock_time: 0.000176 Rows_sent: 2 Rows_examined: 4
lo tanto, en el resultado anterior, podemos ver las columnas indexadas Query_time y Lock_time es mayor que la columna no indexada.
Para un análisis más detallado sobre el estándar de consulta y el rendimiento se puede hacer referencia a continuación enlace:
duplicado Posible de http://stackoverflow.com/questions/7475332/mysql-index-for-group- by-order-by –
@Tichodroma: Vi esa pregunta anteriormente sobre el grupo. Mi escenario es diferente. Necesito el índice para la columna que tiene la condición (dónde) para el filtro de búsqueda. –