Después de investigar en diversos repositorios y sitios de internet finalmente hemos dado con la respuesta que te mostraremos pronto.
Solución:
Actualización: esta respuesta cubre la clasificación general de errores. Para obtener una respuesta más específica sobre cómo manejar mejor la consulta exacta del OP, consulte otras respuestas a esta pregunta
En MySQL, no puede modificar la misma tabla que usa en la parte SELECT.
Este comportamiento está documentado en: http://dev.mysql.com/doc/refman/5.6/en/update.html
Tal vez puedas simplemente unir la mesa a sí misma.
Si la lógica es lo suficientemente simple como para remodelar la consulta, pierda la subconsulta y una la tabla a sí misma, empleando los criterios de selección apropiados. Esto hará que MySQL vea la tabla como dos cosas diferentes, lo que permitirá que se lleven a cabo cambios destructivos.
UPDATE tbl AS a
INNER JOIN tbl AS b ON ....
SET a.col = b.col
Alternativamente, intente anidar la subconsulta más profundamente en una cláusula from …
Si necesita absolutamente la subconsulta, hay una solución, pero es desagradable por varias razones, incluido el rendimiento:
UPDATE tbl SET col = (
SELECT ... FROM (SELECT.... FROM) AS x);
La subconsulta anidada en la cláusula FROM crea un tabla temporal implícitapor lo que no cuenta como la misma tabla que está actualizando.
… pero cuidado con el optimizador de consultas
Sin embargo, tenga en cuenta que a partir de MySQL 5.7.6 y posteriores, el optimizador puede optimizar la subconsulta y aún así generar el error. Por suerte, el optimizer_switch variable se puede utilizar para desactivar este comportamiento; aunque no podría recomendar hacer esto como algo más que una solución a corto plazo, o para pequeñas tareas únicas.
SET optimizer_switch = 'derived_merge=off';
Gracias a Peter V. Mørch por este consejo en los comentarios.
La técnica de ejemplo fue de Baron Schwartz, publicada originalmente en Nabble, parafraseada y extendida aquí.
NexusRex proporcionó una muy buena solución para eliminar con combinación de la misma tabla.
Si haces esto:
DELETE FROM story_category
WHERE category_id NOT IN (
SELECT DISTINCT category.id AS cid FROM category
INNER JOIN story_category ON category_id=category.id
)
vas a recibir un error.
Pero si envuelve la condición en una selección más:
DELETE FROM story_category
WHERE category_id NOT IN (
SELECT cid FROM (
SELECT DISTINCT category.id AS cid FROM category
INNER JOIN story_category ON category_id=category.id
) AS c
)
haría lo correcto!!
Explicación: El optimizador de consultas hace un optimización de fusión derivada para la primera consulta (lo que hace que falle con el error), pero la segunda consulta no califica para el optimización de fusión derivada. Por lo tanto, el optimizador se ve obligado a ejecutar primero la subconsulta.
Él inner join en su subconsulta es innecesario. Parece que desea eliminar las entradas en story_category donde el category_id no está en el category mesa.
Hacer esto:
DELETE FROM story_category
WHERE category_id NOT IN (
SELECT DISTINCT category.id
FROM category);
En vez de eso:
DELETE FROM story_category
WHERE category_id NOT IN (
SELECT DISTINCT category.id
FROM category INNER JOIN
story_category ON category_id=category.id);
Puntuaciones y reseñas
Si estás contento con lo expuesto, eres capaz de dejar una división acerca de qué le añadirías a esta sección.