{"id":1013,"date":"2017-04-02T21:47:48","date_gmt":"2017-04-03T00:47:48","guid":{"rendered":"http:\/\/dbtimewizard.com.br\/blog\/?p=1013"},"modified":"2019-11-11T18:52:11","modified_gmt":"2019-11-11T21:52:11","slug":"funcoes-na-clausula-where-podem-confundir-o-otimizador","status":"publish","type":"post","link":"http:\/\/dbtimewizard.com.br\/blog\/funcoes-na-clausula-where-podem-confundir-o-otimizador\/","title":{"rendered":"Fun\u00e7\u00f5es na cl\u00e1usula WHERE podem confundir o Otimizador?"},"content":{"rendered":"

No artigo “Por que o Otimizador criou um plano de execu\u00e7\u00e3o ineficiente?<\/a><\/strong>” elencamos algumas condi\u00e7\u00f5es que levam o Otimizador a gerar um plano de execu\u00e7\u00e3o ineficiente, neste artigo vamos mostrar com mais detalhes como a utiliza\u00e7\u00e3o de fun\u00e7\u00e3o nas colunas utilizadas na cl\u00e1usula WHERE podem influenciar de maneira negativa o Otimizador.<\/span><\/p>\n

 
\n 
\n <\/p>\n

Colunas com fun\u00e7\u00e3o na cl\u00e1usula WHERE<\/span><\/h2>\n

Para calcular a cardinalidade de uma tabela na instru\u00e7\u00e3o SQL o Otimizador utiliza os filtros informados na cl\u00e1usula WHERE, as opera\u00e7\u00f5es apresentadas na cl\u00e1usula WHERE permitem que o otimizador fa\u00e7a consultas nas estat\u00edsticas para determinar essa cardinalidade. Quando utilizamos uma fun\u00e7\u00e3o numa coluna da cl\u00e1usula WHERE o Otimizador perde essa habilidade de consultar as estat\u00edsticas para determinar a cardinalidade, pois ele n\u00e3o sabe qual valor a coluna vai assumir ap\u00f3s a aplica\u00e7\u00e3o da fun\u00e7\u00e3o no seu valor original. Para suprir a aus\u00eancia dessa informa\u00e7\u00e3o estat\u00edstica o Otimizador estima que a cardinalidade ser\u00e1 1% da quantidade total dos registros da tabela, esse algoritmo n\u00e3o garante que o Otimizador fa\u00e7a uma estimativa de cardinalidade precisa.<\/span><\/p>\n

Para que o Otimizador consiga calcular a cardinalidade de forma mais precisa na situa\u00e7\u00e3o apresentada acima \u00e9 necess\u00e1rio que sejam criadas estat\u00edsticas adicionais na coluna com a fun\u00e7\u00e3o utilizada na cl\u00e1usula WHERE. Para gera\u00e7\u00e3o dessas estat\u00edsticas adicionais devemos utilizar o pacote DBMS_STATS.<\/span><\/p>\n

 <\/p>\n

Para ver na pr\u00e1tica essa situa\u00e7\u00e3o vamos realizar as seguintes opera\u00e7\u00f5es:<\/span><\/p>\n

1) Executar uma consulta utilizando uma coluna com fun\u00e7\u00e3o na cl\u00e1usula WHERE e verificar a cardinalidade estimada pelo Otimizador <\/span>
\n3) Coletar as estist\u00edsticas adicionais da coluna com a fun\u00e7\u00e3o<\/span>
\n4) Executar a mesma consulta novamente e verificar a cardinalidade estimada pelo Otimizador<\/span><\/p>\n

Executar a consulta<\/span><\/h3>\n

Vamos executar uma consulta utilizando uma coluna com fun\u00e7\u00e3o na cl\u00e1usula WHERE e verificar a cardinalidade estimada pelo Otimizador:<\/span><\/p>\n

 <\/p>\n

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
<\/div><\/td>
SQL ><\/span> SELECT *<\/span> FROM V$VERSION<\/span> where rownum <<\/span> 2<\/span>;<\/span>
\n
\nBANNER
\n--------------------------------------------------------------------------------<\/span>
\nOracle Database 11g Enterprise Edition Release 11.<\/span>2.<\/span>0.<\/span>4.<\/span>0 -<\/span> 64bit Production
\n
\nSQL ><\/span> ALTER SESSION SET statistics_level=<\/span>ALL;<\/span>
\n
\nSess\u00e3o alterada.<\/span>
\n
\nSQL ><\/span> SELECT \/* dbtw101 *\/<\/span> count<\/span><\/a>(<\/span>1<\/span>)<\/span> Qtde
\n  2<\/span>    FROM sh.<\/span>customers
\n  3<\/span>   WHERE UPPER(<\/span>CUST_CITY)<\/span> =<\/span> UPPER(<\/span>'Joinville'<\/span>)<\/span>;<\/span>
\n
\n      QTDE
\n----------<\/span>
\n        98<\/span>
\n
\nSQL ><\/span> column sql_id new_value m_sql_id
\nSQL ><\/span> column child_number new_value m_child_no
\nSQL ><\/span> SELECT sql_id,<\/span> child_number
\n  2<\/span>    FROM v$sql<\/span>
\n  3<\/span>   WHERE sql_text LIKE '%dbtw101%'<\/span>
\n  4<\/span>     AND sql_text NOT LIKE '%v$sql%'<\/span>;<\/span>
\n
\nSQL_ID        CHILD_NUMBER
\n-------------<\/span> ------------<\/span>
\n775j44q9u23ak            0<\/span>
\n
\nSQL ><\/span> SELECT *<\/span>
\n  2<\/span>    FROM TABLE (<\/span>dbms_xplan.<\/span>display_cursor (<\/span>'&m_sql_id'<\/span>,&<\/span>m_child_no,<\/span>'ALLSTATS LAST'<\/span>)<\/span>)<\/span>;<\/span>
\n
\nPLAN_TABLE_OUTPUT
\n--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------<\/span>
\nSQL_ID  775j44q9u23ak,<\/span> child number 0<\/span>
\n-------------------------------------<\/span>
\nSELECT \/* dbtw101 *\/<\/span> count<\/span><\/a>(<\/span>:<\/span>"SYS_B_0"<\/span>)<\/span> Qtde   FROM sh.<\/span>customers  WHERE
\nUPPER(<\/span>CUST_CITY)<\/span> =<\/span> UPPER(<\/span>:<\/span>"SYS_B_1"<\/span>)<\/span>
\n
\nPlan hash<\/span><\/a> value:<\/span> 296924608<\/span>
\n
\n------------------------------------------------------------------------------------------<\/span>
\n|<\/span> Id  |<\/span> Operation          |<\/span> Name      |<\/span> Starts |<\/span> E-<\/span>Rows |<\/span> A-<\/span>Rows |<\/span>   A-<\/span>Time<\/span><\/a>   |<\/span> Buffers |<\/span>
\n------------------------------------------------------------------------------------------<\/span>
\n|<\/span>   0<\/span> |<\/span> SELECT STATEMENT   |<\/span>           |<\/span>      1<\/span> |<\/span>        |<\/span>      1<\/span> |<\/span>00<\/span>:<\/span>00<\/span>:<\/span>00.01<\/span> |<\/span>    1456<\/span> |<\/span>
\n|<\/span>   1<\/span> |<\/span>  SORT<\/span><\/a> AGGREGATE<\/span><\/a>    |<\/span>           |<\/span>      1<\/span> |<\/span>      1<\/span> |<\/span>      1<\/span> |<\/span>00<\/span>:<\/span>00<\/span>:<\/span>00.01<\/span> |<\/span>    1456<\/span> |<\/span>
\n|*<\/span>  2<\/span> |<\/span>   TABLE ACCESS FULL|<\/span> CUSTOMERS |<\/span>      1<\/span> |<\/span>    555<\/span> |<\/span>     98<\/span> |<\/span>00<\/span>:<\/span>00<\/span>:<\/span>00.01<\/span> |<\/span>    1456<\/span> |<\/span>
\n------------------------------------------------------------------------------------------<\/span>
\n
\nPredicate Information (<\/span>identified by operation id)<\/span>:<\/span>
\n---------------------------------------------------<\/span>
\n
\n   2<\/span> -<\/span> filter(<\/span>UPPER(<\/span>"CUST_CITY"<\/span>)<\/span>=<\/span>UPPER(<\/span>:<\/span>SYS_B_1)<\/span>)<\/span>
\n
\n
\n20<\/span> linhas selecionadas.<\/span>
\n
\nSQL ><\/span> column "Num. linhas na tabela"<\/span> new_value num_lin_tot
\nSQL ><\/span> select count<\/span><\/a>(<\/span>1<\/span>)<\/span> "Num. linhas na tabela"<\/span> from sh.<\/span>customers;<\/span>
\n
\nNum.<\/span> linhas na tabela
\n---------------------<\/span>
\n                55500<\/span>
\n
\nSQL ><\/span> select round<\/span><\/a>(<\/span>&<\/span>num_lin_tot*<\/span>0.01<\/span>)<\/span> CARDINALIDADE from dual;<\/span>
\nantigo   1<\/span>:<\/span> select round<\/span><\/a>(<\/span>&<\/span>num_lin_tot*<\/span>0.01<\/span>)<\/span> CARDINALIDADE from dual
\nnovo   1<\/span>:<\/span> select round<\/span><\/a>(<\/span>     55500<\/span>*<\/span>0.01<\/span>)<\/span> CARDINALIDADE from dual
\n
\nCARDINALIDADE
\n-------------<\/span>
\n          555<\/span>
\n
\nSQL ><\/span><\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

 <\/p>\n

No plano de execu\u00e7\u00e3o verificamos que o Otimizador estimou que a cardinalidade da tabela “CUSTOMERS” seriam 555 registros (E-ROWS), quando na verdade foram 98 registros (A-ROWS).<\/span><\/p>\n

O Otimizador calculou a cardinalidade como 555 pois ele usou o algoritimo de 1% da quantidade total de registros da tabela (55500).<\/span><\/p>\n

Coletar das estist\u00edsticas adicionais<\/span><\/h3>\n

Para ajudar o Otimizador vamos criar as estat\u00edsticas para a coluna utilizando a mesma fun\u00e7\u00e3o presente na cl\u00e1usula WHERE da consulta, para isso \u00e9 necess\u00e1rio utilizar a cla\u00fasula “method_opt=> ‘FOR ALL COLUMNS SIZE SKEWONLY for columns (UPPER(CUST_CITY))'” na coleta de estat\u00edsticas com o pacote DBMS_STATS.<\/span><\/p>\n

 <\/p>\n

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
<\/div><\/td>
SQL ><\/span> SELECT column_name,<\/span> num_distinct,<\/span> histogram
\n  2<\/span>    FROM dba_tab_col_statistics
\n  3<\/span>   WHERE table_name =<\/span> 'CUSTOMERS'<\/span>
\n  4<\/span>     AND owner =<\/span> 'SH'<\/span>;<\/span>
\n
\nCOLUMN_NAME                    NUM_DISTINCT HISTOGRAM
\n------------------------------<\/span> ------------<\/span> ---------------<\/span>
\nCUST_ID                               55500<\/span> HEIGHT BALANCED
\nCUST_FIRST_NAME                        1300<\/span> HEIGHT BALANCED
\nCUST_LAST_NAME                          908<\/span> HEIGHT BALANCED
\nCUST_GENDER                               2<\/span> FREQUENCY
\nCUST_YEAR_OF_BIRTH                       75<\/span> FREQUENCY
\nCUST_MARITAL_STATUS                      11<\/span> FREQUENCY
\nCUST_STREET_ADDRESS                   49900<\/span> HEIGHT BALANCED
\nCUST_POSTAL_CODE                        623<\/span> HEIGHT BALANCED
\nCUST_CITY                               620<\/span> HEIGHT BALANCED
\nCUST_CITY_ID                            620<\/span> HEIGHT BALANCED
\nCUST_STATE_PROVINCE                     145<\/span> FREQUENCY
\nCUST_STATE_PROVINCE_ID                  145<\/span> FREQUENCY
\nCOUNTRY_ID                               19<\/span> FREQUENCY
\nCUST_MAIN_PHONE_NUMBER                51344<\/span> HEIGHT BALANCED
\nCUST_INCOME_LEVEL                        12<\/span> FREQUENCY
\nCUST_CREDIT_LIMIT                         8<\/span> FREQUENCY
\nCUST_EMAIL                             1699<\/span> HEIGHT BALANCED
\nCUST_TOTAL                                1<\/span> FREQUENCY
\nCUST_TOTAL_ID                             1<\/span> FREQUENCY
\nCUST_SRC_ID                               0<\/span> NONE
\nCUST_EFF_FROM                             1<\/span> FREQUENCY
\nCUST_EFF_TO                               0<\/span> NONE
\nCUST_VALID                                2<\/span> FREQUENCY
\n
\n23<\/span> linhas selecionadas.<\/span>
\n
\nSQL ><\/span> exec<\/span><\/a> dbms_stats.<\/span>gather_table_stats(<\/span>ownname=><\/span> 'SH'<\/span>,<\/span> tabname=><\/span> 'CUSTOMERS'<\/span>,<\/span> cascade=><\/span> true<\/span>,<\/span> method_opt=><\/span> 'FOR ALL COLUMNS SIZE SKEWONLY for columns (UPPER(CUST_CITY))'<\/span>)<\/span>;<\/span>
\n
\nProcedimento PL\/<\/span>SQL conclu\u00eddo<\/span> com sucesso.<\/span>
\n
\nSQL ><\/span> SELECT column_name,<\/span> num_distinct,<\/span> histogram
\n  2<\/span>    FROM dba_tab_col_statistics
\n  3<\/span>   WHERE table_name =<\/span> 'CUSTOMERS'<\/span>
\n  4<\/span>     AND owner =<\/span> 'SH'<\/span>;<\/span>
\n
\nCOLUMN_NAME                    NUM_DISTINCT HISTOGRAM
\n------------------------------<\/span> ------------<\/span> ---------------<\/span>
\nSYS_STUH1VS5X9F1_EEZ1S2XSM741O          620<\/span> HEIGHT BALANCED
\nCUST_ID                               55500<\/span> HEIGHT BALANCED
\nCUST_FIRST_NAME                        1300<\/span> HEIGHT BALANCED
\nCUST_LAST_NAME                          908<\/span> HEIGHT BALANCED
\nCUST_GENDER                               2<\/span> FREQUENCY
\nCUST_YEAR_OF_BIRTH                       75<\/span> FREQUENCY
\nCUST_MARITAL_STATUS                      11<\/span> FREQUENCY
\nCUST_STREET_ADDRESS                   49900<\/span> HEIGHT BALANCED
\nCUST_POSTAL_CODE                        623<\/span> HEIGHT BALANCED
\nCUST_CITY                               620<\/span> HEIGHT BALANCED
\nCUST_CITY_ID                            620<\/span> HEIGHT BALANCED
\nCUST_STATE_PROVINCE                     145<\/span> FREQUENCY
\nCUST_STATE_PROVINCE_ID                  145<\/span> FREQUENCY
\nCOUNTRY_ID                               19<\/span> FREQUENCY
\nCUST_MAIN_PHONE_NUMBER                51344<\/span> HEIGHT BALANCED
\nCUST_INCOME_LEVEL                        12<\/span> FREQUENCY
\nCUST_CREDIT_LIMIT                         8<\/span> FREQUENCY
\nCUST_EMAIL                             1699<\/span> HEIGHT BALANCED
\nCUST_TOTAL                                1<\/span> FREQUENCY
\nCUST_TOTAL_ID                             1<\/span> FREQUENCY
\nCUST_SRC_ID                               0<\/span> NONE
\nCUST_EFF_FROM                             1<\/span> FREQUENCY
\nCUST_EFF_TO                               0<\/span> NONE
\nCUST_VALID                                2<\/span> FREQUENCY
\n
\n24<\/span> linhas selecionadas.<\/span>
\n
\nSQL ><\/span><\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

 <\/p>\n

Ap\u00f3s a execu\u00e7\u00e3o do pacote DBMS_STATS, podemos observar que existe uma coluna (linha 45) com nome gerado pelo sistema (SYS_STUH1VS5X9F1_EEZ1S2XSM741O) que representa as estat\u00edsticas geradas para a coluna com a fun\u00e7\u00e3o UPPER().<\/span><\/p>\n

Executar a consulta novamente<\/span><\/h3>\n

Finalmente vamos executar a consulta novamente e verificar a qualidade da cardinalidade estimada pelo Otimizador.<\/span><\/p>\n

 <\/p>\n

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
<\/div><\/td>
SQL ><\/span> ALTER SESSION SET statistics_level=<\/span>ALL;<\/span>
\n
\nSess\u00e3o alterada.<\/span>
\n
\nSQL ><\/span> SELECT \/* dbtw102 *\/<\/span> count<\/span><\/a>(<\/span>1<\/span>)<\/span> Qtde
\n  2<\/span>    FROM sh.<\/span>customers
\n  3<\/span>   WHERE UPPER(<\/span>CUST_CITY)<\/span> =<\/span> UPPER(<\/span>'Joinville'<\/span>)<\/span>;<\/span>
\n
\n      QTDE
\n----------<\/span>
\n        98<\/span>
\n
\nSQL ><\/span> column sql_id new_value m_sql_id
\nSQL ><\/span> column child_number new_value m_child_no
\nSQL ><\/span> SELECT sql_id,<\/span> child_number
\n  2<\/span>    FROM v$sql<\/span>
\n  3<\/span>   WHERE sql_text LIKE '%dbtw102%'<\/span>
\n  4<\/span>     AND sql_text NOT LIKE '%v$sql%'<\/span>;<\/span>
\n
\nSQL_ID        CHILD_NUMBER
\n-------------<\/span> ------------<\/span>
\ncdhk4zdy1qa2b            0<\/span>
\n
\nSQL ><\/span> SELECT *<\/span>
\n  2<\/span>    FROM TABLE (<\/span>dbms_xplan.<\/span>display_cursor (<\/span>'&m_sql_id'<\/span>,&<\/span>m_child_no,<\/span>'ALLSTATS LAST'<\/span>)<\/span>)<\/span>;<\/span>
\nantigo   2<\/span>:<\/span>   FROM TABLE (<\/span>dbms_xplan.<\/span>display_cursor (<\/span>'&m_sql_id'<\/span>,&<\/span>m_child_no,<\/span>'ALLSTATS LAST'<\/span>)<\/span>)<\/span>
\nnovo   2<\/span>:<\/span>   FROM TABLE (<\/span>dbms_xplan.<\/span>display_cursor (<\/span>'cdhk4zdy1qa2b'<\/span>,<\/span>         0<\/span>,<\/span>'ALLSTATS LAST'<\/span>)<\/span>)<\/span>
\n
\nPLAN_TABLE_OUTPUT
\n--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------<\/span>
\nSQL_ID  cdhk4zdy1qa2b,<\/span> child number 0<\/span>
\n-------------------------------------<\/span>
\nSELECT \/* dbtw102 *\/<\/span> count<\/span><\/a>(<\/span>:<\/span>"SYS_B_0"<\/span>)<\/span> Qtde   FROM sh.<\/span>customers  WHERE
\nUPPER(<\/span>CUST_CITY)<\/span> =<\/span> UPPER(<\/span>:<\/span>"SYS_B_1"<\/span>)<\/span>
\n
\nPlan hash<\/span><\/a> value:<\/span> 296924608<\/span>
\n
\n------------------------------------------------------------------------------------------<\/span>
\n|<\/span> Id  |<\/span> Operation          |<\/span> Name      |<\/span> Starts |<\/span> E-<\/span>Rows |<\/span> A-<\/span>Rows |<\/span>   A-<\/span>Time<\/span><\/a>   |<\/span> Buffers |<\/span>
\n------------------------------------------------------------------------------------------<\/span>
\n|<\/span>   0<\/span> |<\/span> SELECT STATEMENT   |<\/span>           |<\/span>      1<\/span> |<\/span>        |<\/span>      1<\/span> |<\/span>00<\/span>:<\/span>00<\/span>:<\/span>00.01<\/span> |<\/span>    1456<\/span> |<\/span>
\n|<\/span>   1<\/span> |<\/span>  SORT<\/span><\/a> AGGREGATE<\/span><\/a>    |<\/span>           |<\/span>      1<\/span> |<\/span>      1<\/span> |<\/span>      1<\/span> |<\/span>00<\/span>:<\/span>00<\/span>:<\/span>00.01<\/span> |<\/span>    1456<\/span> |<\/span>
\n|*<\/span>  2<\/span> |<\/span>   TABLE ACCESS FULL|<\/span> CUSTOMERS |<\/span>      1<\/span> |<\/span>     68<\/span> |<\/span>     98<\/span> |<\/span>00<\/span>:<\/span>00<\/span>:<\/span>00.01<\/span> |<\/span>    1456<\/span> |<\/span>
\n------------------------------------------------------------------------------------------<\/span>
\n
\nPredicate Information (<\/span>identified by operation id)<\/span>:<\/span>
\n---------------------------------------------------<\/span>
\n
\n   2<\/span> -<\/span> filter(<\/span>UPPER(<\/span>"CUST_CITY"<\/span>)<\/span>=<\/span>UPPER(<\/span>:<\/span>SYS_B_1)<\/span>)<\/span>
\n
\n
\n20<\/span> linhas selecionadas.<\/span>
\n
\nSQL ><\/span><\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

 <\/p>\n

Analisando o plano de execu\u00e7\u00e3o acima verificamos que a cardinalidade estimada pelo Otimizador ficou muito pr\u00f3xima da realidade (E-ROWS=68 registros), para uma quantidade real de 98 registros (A-ROWS).<\/span><\/p>\n

Conclus\u00e3o<\/span><\/h2>\n

Nesse artigo verificamos na pr\u00e1tica que as estat\u00edsticas, na sua configura\u00e7\u00e3o padr\u00e3o, n\u00e3o conseguem suprir todas as informa\u00e7\u00f5es que o Otimizador necessita para realizar estimativas de cardinalidade com precis\u00e3o, o gerenciamento da coleta de estat\u00edsticas \u00e9 fundamental para garantir a cria\u00e7\u00e3o de estat\u00edsticas adicionais de colunas de tabelas que utilizem fun\u00e7\u00e3o nos filtros da cl\u00e1usula WHERE das instru\u00e7\u00f5es SQL. O pacote DBMS_STATS pode e deve ser utilizado para fazer os ajustes necess\u00e1rios no processo de coleta de estat\u00edsticas de acordo com as caracter\u00edsticas dos dados e como eles s\u00e3o acessados.<\/span><\/p>\n

Refer\u00eancias<\/span><\/h2>\n

http:\/\/gavinsoorma.com\/wp-content\/uploads\/2011\/03\/top_tips_for_optimal_sql_execution.pdf<\/a><\/span><\/strong><\/p>\n

https:\/\/docs.oracle.com\/database\/121\/ARPLS\/d_stats.htm#ARPLS68491<\/a><\/span><\/strong><\/p>\n

 
\n 
\n\"Promo-D75L\"<\/a><\/p>\n

\"video-02\"<\/a>
\n 
\n 
\n 
\n 
\n 
\n 
\n 
\n 
\n 
\n 
\n 
\n 
\n 
\n <\/p>\n","protected":false},"excerpt":{"rendered":"

No artigo “Por que o Otimizador criou um plano de execu\u00e7\u00e3o ineficiente?” elencamos algumas condi\u00e7\u00f5es que levam o Otimizador a gerar um plano de execu\u00e7\u00e3o ineficiente, neste artigo vamos mostrar com mais detalhes como a utiliza\u00e7\u00e3o de fun\u00e7\u00e3o nas colunas utilizadas na cl\u00e1usula WHERE podem influenciar de maneira negativa o Otimizador.       Colunas com fun\u00e7\u00e3o na cl\u00e1usula WHERE<\/p>\n","protected":false},"author":2,"featured_media":1014,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[71],"tags":[129,128,6,42,163,10],"class_list":["post-1013","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-estatisticas","tag-cardinalidade","tag-cardinality","tag-cbo","tag-cost-base-optimizer","tag-dbms_stats","tag-otimizador"],"aioseo_notices":[],"_links":{"self":[{"href":"http:\/\/dbtimewizard.com.br\/blog\/wp-json\/wp\/v2\/posts\/1013","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/dbtimewizard.com.br\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/dbtimewizard.com.br\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/dbtimewizard.com.br\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"http:\/\/dbtimewizard.com.br\/blog\/wp-json\/wp\/v2\/comments?post=1013"}],"version-history":[{"count":15,"href":"http:\/\/dbtimewizard.com.br\/blog\/wp-json\/wp\/v2\/posts\/1013\/revisions"}],"predecessor-version":[{"id":2086,"href":"http:\/\/dbtimewizard.com.br\/blog\/wp-json\/wp\/v2\/posts\/1013\/revisions\/2086"}],"wp:featuredmedia":[{"embeddable":true,"href":"http:\/\/dbtimewizard.com.br\/blog\/wp-json\/wp\/v2\/media\/1014"}],"wp:attachment":[{"href":"http:\/\/dbtimewizard.com.br\/blog\/wp-json\/wp\/v2\/media?parent=1013"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/dbtimewizard.com.br\/blog\/wp-json\/wp\/v2\/categories?post=1013"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/dbtimewizard.com.br\/blog\/wp-json\/wp\/v2\/tags?post=1013"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}