{"id":91048,"date":"2020-08-08T01:42:02","date_gmt":"2020-08-07T23:42:02","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/ne-stoit-polzovatsya-offset-i-limit-v-zaprosah-s-razbieniem-na-straniczy"},"modified":"2020-08-08T01:42:02","modified_gmt":"2020-08-07T23:42:02","slug":"ne-stoit-polzovatsya-offset-i-limit-v-zaprosah-s-razbieniem-na-straniczy","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/ne-stoit-polzovatsya-offset-i-limit-v-zaprosah-s-razbieniem-na-straniczy","title":{"rendered":"No se debe utilizar OFFSET y LIMIT en consultas con paginaci\u00f3n","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Han pasado los d\u00edas en que no hab\u00eda que preocuparse por la optimizaci\u00f3n del rendimiento de las bases de datos. El tiempo no se detiene. Cada nuevo empresario del sector tecnol\u00f3gico quiere crear el pr\u00f3ximo Facebook, mientras se esfuerza por recopilar todos los datos a los que puede acceder. Estos datos son necesarios para que las empresas entrenen mejor los modelos que ayudan a ganar dinero. En estas condiciones, los programadores deben crear API que permitan trabajar de manera r\u00e1pida y confiable con grandes vol\u00famenes de informaci\u00f3n.<\/p>\n

\"No<\/a><\/noindex>
\n<\/a><\/noindex>
\nSi has estado dise\u00f1ando partes servidoras de aplicaciones o bases de datos durante un tiempo, probablemente hayas escrito c\u00f3digo para ejecutar consultas con paginaci\u00f3n. Por ejemplo, algo as\u00ed:<\/p>\n

SELECT * FROM table_name LIMIT 10 OFFSET 40\n<\/code><\/pre>\n
\n\u00bfEs as\u00ed?<\/p>\n
Pero si realizaste la paginaci\u00f3n de esta manera, lamento informarte que lo hiciste de una manera que no es la m\u00e1s eficiente.<\/p>\n
\u00bfQuieres rebatirme? Puedes<\/a><\/noindex> no<\/a><\/noindex> gastar<\/a><\/noindex> el tiempo<\/a><\/noindex>. Slack<\/a><\/noindex>, Shopify<\/a><\/noindex> y Mixmax<\/a><\/noindex> ya utilizan t\u00e9cnicas de las cuales quiero hablar hoy.<\/p>\n
Nombrar al menos a un desarrollador de backend que nunca haya utilizado OFFSET<\/code> y LIMIT<\/code> para ejecutar consultas con paginaci\u00f3n. En un MVP (Producto M\u00ednimo Viable) y en proyectos donde se utilizan peque\u00f1os vol\u00famenes de datos, este enfoque es bastante aplicable. Se podr\u00eda decir que 'simplemente funciona'.<\/p>\n
Pero si necesitas crear sistemas confiables y eficientes desde cero, deber\u00edas preocuparte de antemano por la eficiencia de las consultas a las bases de datos utilizadas en tales sistemas.<\/p>\n
Hoy hablaremos sobre los problemas asociados con las implementaciones de mecanismos de ejecuci\u00f3n de consultas con paginaci\u00f3n que son ampliamente utilizadas (desafortunadamente). Y sobre c\u00f3mo lograr un alto rendimiento al ejecutar tales consultas.<\/p>\n
\u00bfQu\u00e9 est\u00e1 mal con OFFSET y LIMIT?<\/h2>\n
\nComo se mencion\u00f3 anteriormente, OFFSET<\/code> y LIMIT<\/code> se desempe\u00f1an excelentemente en proyectos donde no es necesario trabajar con grandes vol\u00famenes de datos.<\/p>\n
El problema surge cuando la base de datos crece a tal tama\u00f1o que ya no cabe en la memoria del servidor. Pero, aun as\u00ed, al trabajar con esta base de datos, es necesario utilizar consultas con paginaci\u00f3n.<\/p>\n
Para que este problema se presente, es necesario que surja una situaci\u00f3n en la que la base de datos recurra a una operaci\u00f3n ineficiente de escaneo completo de tabla (Full Table Scan) al ejecutar cada consulta con paginaci\u00f3n (mientras tanto, pueden ocurrir operaciones de inserci\u00f3n y eliminaci\u00f3n de datos, y no necesitamos los datos obsoletos).<\/p>\n
\u00bfQu\u00e9 es un \"escaneo completo de tabla\" (o \"lectura secuencial de tabla\", Sequential Scan)? Es una operaci\u00f3n en la que la base de datos lee secuencialmente cada fila de la tabla, es decir, los datos contenidos en ella, y verifica su conformidad con la condici\u00f3n dada. Se sabe que este tipo de escaneo de tablas es el m\u00e1s lento. Esto se debe a que durante su ejecuci\u00f3n se realizan muchas operaciones de entrada\/salida que implican el subsistema de disco del servidor. La situaci\u00f3n se agrava por las latencias asociadas con el manejo de datos almacenados en los discos, y el hecho de que la transferencia de datos del disco a la memoria es una operaci\u00f3n intensiva en recursos.<\/p>\n
Por ejemplo, tiene registros de 100000000 de usuarios y est\u00e1 ejecutando una consulta con la construcci\u00f3n OFFSET 50000000<\/code>. Esto significa que la base de datos tendr\u00e1 que cargar todos estos registros (\u00a1y ni siquiera los necesitamos!), colocarlos en memoria y solo despu\u00e9s tomar, digamos, 20 resultados, que se mencionan en LIMIT<\/code>.<\/p>\n
Digamos que podr\u00eda verse as\u00ed: \"seleccionar filas de 50000 a 50020 de 100000\". Es decir, el sistema necesitar\u00e1 cargar primero 50000 filas para ejecutar la consulta. \u00bfVes cu\u00e1ntos trabajos innecesarios tendr\u00e1 que realizar?<\/p>\n
Si no me crees, mira el ejemplo que cre\u00e9 utilizando las capacidades de db-fiddle.com<\/a><\/noindex>.\u00a0<\/p>\n
\"No
\nEjemplo en db-fiddle.com<\/i><\/p>\n
All\u00ed, a la izquierda, en el campo Schema SQL<\/code>, hay c\u00f3digo que realiza la inserci\u00f3n en la base de datos de 100000 filas, y a la derecha, en el campo Query SQL<\/code>, se muestran dos consultas. La primera, lenta, es as\u00ed:<\/p>\n
SELECT *\nFROM `docs`\nLIMIT 10 OFFSET 85000;\n<\/code><\/pre>\n
\nY la segunda, que representa una soluci\u00f3n eficiente para la misma tarea, es:<\/p>\n
SELECT *\nFROM `docs`\nWHERE id > 85000\nLIMIT 10;\n<\/code><\/pre>\n
\nPara ejecutar estas consultas, solo necesita hacer clic en el bot\u00f3n Ejecutar<\/code> en la parte superior de la p\u00e1gina. Al hacerlo, compararemos la informaci\u00f3n sobre los tiempos de ejecuci\u00f3n de las consultas. Resulta que ejecutar una consulta ineficiente toma, al menos, 30 veces m\u00e1s tiempo que ejecutar la segunda (de una ejecuci\u00f3n a otra, este tiempo var\u00eda; por ejemplo, el sistema puede informar que la primera consulta tom\u00f3 37 ms, mientras que la segunda \u2014 1 ms).<\/p>\n
Y si hay m\u00e1s datos, todo se ver\u00e1 a\u00fan peor (para comprobarlo, eche un vistazo a mi ejemplo<\/a><\/noindex> con 10 millones de filas).<\/p>\n
Lo que acabamos de discutir deber\u00eda darte una idea de c\u00f3mo, en realidad, se procesan las consultas en las bases de datos.<\/p>\n
Ten en cuenta que cuanto mayor sea el valor OFFSET<\/code> m\u00e1s tiempo tomar\u00e1 ejecutar la consulta.<\/p>\n
\u00bfQu\u00e9 se debe usar en lugar de la combinaci\u00f3n OFFSET y LIMIT?<\/h2>\n
\nEn lugar de la combinaci\u00f3n OFFSET<\/code> y LIMIT<\/code> deber\u00edas usar una construcci\u00f3n basada en el siguiente esquema:<\/p>\n
SELECT * FROM table_name WHERE id > 10 LIMIT 20\n<\/code><\/pre>\n
\nEsta es la ejecuci\u00f3n de una consulta con paginaci\u00f3n, basada en un cursor (Cursor based pagination).<\/p>\n
En lugar de almacenar localmente los actuales OFFSET<\/code> y LIMIT<\/code> y enviarlos con cada consulta, deber\u00edas almacenar la \u00faltima clave primaria recibida (normalmente es ID<\/code>) y LIMIT<\/code>, lo que resultar\u00e1 en consultas que se parecer\u00e1n a la anterior.<\/p>\n
\u00bfPor qu\u00e9? La raz\u00f3n es que al especificar expl\u00edcitamente el identificador de la \u00faltima fila le\u00edda, est\u00e1s informando a tu sistema de gesti\u00f3n de bases de datos sobre d\u00f3nde debe comenzar a buscar los datos necesarios. Adem\u00e1s, la b\u00fasqueda, gracias al uso de la clave, se llevar\u00e1 a cabo de manera eficiente, el sistema no tendr\u00e1 que distraerse con filas que est\u00e1n fuera del rango especificado.<\/p>\n
Veamos la siguiente comparaci\u00f3n de rendimiento entre varias consultas. Aqu\u00ed hay una consulta ineficiente.<\/p>\n
\"No
\nConsulta lenta<\/i><\/p>\n
Y aqu\u00ed est\u00e1 la versi\u00f3n optimizada de esta consulta.<\/p>\n
\"No
\nConsulta r\u00e1pida<\/i><\/p>\n
Ambas consultas devuelven exactamente la misma cantidad de datos. Pero la primera toma 12,80 segundos en ejecutarse, mientras que la segunda toma 0,01 segundos. \u00bfSientes la diferencia?<\/p>\n
Problemas potenciales<\/h2>\n
\nPara garantizar el funcionamiento efectivo del m\u00e9todo propuesto para ejecutar consultas, es necesario que en la tabla haya una columna (o columnas) que contenga \u00edndices \u00fanicos y secuenciales, como un identificador entero. En algunos casos espec\u00edficos, esto puede determinar el \u00e9xito de la aplicaci\u00f3n de tales consultas para mejorar la velocidad de trabajo con la base de datos.<\/p>\n
Por supuesto, al construir consultas, es importante tener en cuenta las caracter\u00edsticas de la arquitectura de las tablas y elegir los mecanismos que mejor se desempe\u00f1en con las tablas existentes. Por ejemplo, si necesita trabajar en consultas con grandes vol\u00famenes de datos relacionados, puede encontrar interesante esta<\/a><\/noindex> art\u00edculo.<\/p>\n
Si nos enfrentamos a la falta de una clave primaria, por ejemplo, si hay una tabla con una relaci\u00f3n de 'muchos a muchos', entonces el enfoque tradicional que prev\u00e9 el uso de OFFSET<\/code> y LIMIT<\/code>, seguramente nos ser\u00e1 \u00fatil. Sin embargo, su aplicaci\u00f3n puede llevar a la ejecuci\u00f3n de consultas potencialmente lentas. En tales casos, recomendar\u00eda usar una clave primaria con auto-incremento, incluso si solo se necesita para organizar la ejecuci\u00f3n de consultas paginadas.<\/p>\n
Si le interesa este tema \u2014 aqu\u00ed<\/a><\/noindex>, aqu\u00ed<\/a><\/noindex> y aqu\u00ed<\/a><\/noindex> \u2014 algunos materiales \u00fatiles.<\/p>\n
Resultados<\/h2>\n
\nLa conclusi\u00f3n principal que podemos sacar es que, independientemente del tama\u00f1o de las bases de datos, siempre se debe analizar la velocidad de ejecuci\u00f3n de las consultas. En la actualidad, la escalabilidad de las soluciones es extremadamente importante, y si desde el principio se dise\u00f1a correctamente un sistema, esto puede evitar que el desarrollador enfrente muchos problemas en el futuro.<\/p>\n
\u00bfC\u00f3mo analiza y optimiza las consultas a bases de datos?<\/b><\/p>\n
\"No<\/a><\/noindex>
\n
Fuente: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
\u041f\u0440\u043e\u0448\u043b\u0438 \u0442\u0435 \u0434\u043d\u0438, \u043a\u043e\u0433\u0434\u0430 \u043d\u0435 \u043d\u0430\u0434\u043e \u0431\u044b\u043b\u043e \u0431\u0435\u0441\u043f\u043e\u043a\u043e\u0438\u0442\u044c\u0441\u044f \u043e\u0431 \u043e\u043f\u0442\u0438\u043c\u0438\u0437\u0430\u0446\u0438\u0438 \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u0438 \u0431\u0430\u0437 \u0434\u0430\u043d\u043d\u044b\u0445. \u0412\u0440\u0435\u043c\u044f \u043d\u0435 \u0441\u0442\u043e\u0438\u0442 \u043d\u0430 \u043c\u0435\u0441\u0442\u0435. \u041a\u0430\u0436\u0434\u044b\u0439 \u043d\u043e\u0432\u044b\u0439 \u0431\u0438\u0437\u043d\u0435\u0441\u043c\u0435\u043d \u0438\u0437 \u0441\u0444\u0435\u0440\u044b \u0432\u044b\u0441\u043e\u043a\u0438\u0445 \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u0439 \u0445\u043e\u0447\u0435\u0442 \u0441\u043e\u0437\u0434\u0430\u0442\u044c \u043e\u0447\u0435\u0440\u0435\u0434\u043d\u043e\u0439 Facebook, \u0441\u0442\u0440\u0435\u043c\u044f\u0441\u044c \u043f\u0440\u0438 \u044d\u0442\u043e\u043c \u0441\u043e\u0431\u0438\u0440\u0430\u0442\u044c \u0432\u0441\u0435 \u0434\u0430\u043d\u043d\u044b\u0435, \u0434\u043e \u043a\u043e\u0442\u043e\u0440\u044b\u0445 \u043c\u043e\u0436\u0435\u0442 \u0434\u043e\u0442\u044f\u043d\u0443\u0442\u044c\u0441\u044f. \u042d\u0442\u0438 \u0434\u0430\u043d\u043d\u044b\u0435 \u043d\u0443\u0436\u043d\u044b \u0431\u0438\u0437\u043d\u0435\u0441\u0443 \u0434\u043b\u044f \u0431\u043e\u043b\u0435\u0435 \u043a\u0430\u0447\u0435\u0441\u0442\u0432\u0435\u043d\u043d\u043e\u0433\u043e \u043e\u0431\u0443\u0447\u0435\u043d\u0438\u044f \u043c\u043e\u0434\u0435\u043b\u0435\u0439, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043f\u043e\u043c\u043e\u0433\u0430\u044e\u0442 \u0437\u0430\u0440\u0430\u0431\u0430\u0442\u044b\u0432\u0430\u0442\u044c. \u0412 \u0442\u0430\u043a\u0438\u0445 \u0443\u0441\u043b\u043e\u0432\u0438\u044f\u0445 \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u0438\u0441\u0442\u0430\u043c […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":91049,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-91048","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47No use OFFSET y LIMIT en consultas con paginaci\u00f3n | ProHoster","description":"Han pasado los d\u00edas en que no hab\u00eda que preocuparse por la optimizaci\u00f3n del rendimiento de las bases de datos. El tiempo no se detiene.","canonical_url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/ne-stoit-polzovatsya-offset-i-limit-v-zaprosah-s-razbieniem-na-straniczy","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"es_ES","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041d\u0435 \u0441\u0442\u043e\u0438\u0442 \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u044c\u0441\u044f OFFSET \u0438 LIMIT \u0432 \u0437\u0430\u043f\u0440\u043e\u0441\u0430\u0445 \u0441 \u0440\u0430\u0437\u0431\u0438\u0435\u043d\u0438\u0435\u043c \u043d\u0430 \u0441\u0442\u0440\u0430\u043d\u0438\u0446\u044b | ProHoster","og:description":"\u041f\u0440\u043e\u0448\u043b\u0438 \u0442\u0435 \u0434\u043d\u0438, \u043a\u043e\u0433\u0434\u0430 \u043d\u0435 \u043d\u0430\u0434\u043e \u0431\u044b\u043b\u043e \u0431\u0435\u0441\u043f\u043e\u043a\u043e\u0438\u0442\u044c\u0441\u044f \u043e\u0431 \u043e\u043f\u0442\u0438\u043c\u0438\u0437\u0430\u0446\u0438\u0438 \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u0438 \u0431\u0430\u0437 \u0434\u0430\u043d\u043d\u044b\u0445. \u0412\u0440\u0435\u043c\u044f \u043d\u0435 \u0441\u0442\u043e\u0438\u0442 \u043d\u0430 \u043c\u0435\u0441\u0442\u0435.","og:url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/ne-stoit-polzovatsya-offset-i-limit-v-zaprosah-s-razbieniem-na-straniczy","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-08-07T23:42:02+00:00","article:modified_time":"2020-08-07T23:42:02+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"91048","title":null,"description":null,"keywords":null,"keyphrases":{"focus":[],"additional":[]},"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 12:35:24","updated":"2026-08-11 12:50:11","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/91048","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/comments?post=91048"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/91048\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media\/91049"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media?parent=91048"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/categories?post=91048"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/tags?post=91048"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}