Design Considerations local traditional message center project - [] unread messages

 

Today there is a SQL occupy high system load, IO load takes up 30%. After the user login function is to display the number of unread messages. Since the function as long as the point of the system will check this SQL.
Resulting in the morning four hours call 100 000 times. 
COUNT the SELECT (. 1)
  the FROM WORKBENCH_MES Tl, T2 WORKBENCH_MES_REL
 the WHERE T1.MES_ID = T2.MES_ID
   the AND T2.RECIPIENT_ID = '83DB7DD7505B4C90831717AB18881C69'
   the AND T2.IS_READ = 'N' 
   the AND T1.SEND_DATE> = the TO_DATE ( '2017-08-04' , 'YYYY-the MM-DD')
   the AND T1.SEND_DATE <the TO_DATE ( '2018-02-04', 'YYYY-the MM-DD') +. 1;

 Just yesterday, this SQL execution plans changed. Because before consumption, although implementation often, the problem is not large, the implementation of plans to become a full-table index came after.

-------------------------------------------------------------------------------------------------------------------
| Id  | Operation                             | Name                      | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                      |                           |       |       |   258 (100)|          |
|   1 |  SORT AGGREGATE                       |                           |     1 |   113 |            |          |
|*  2 |   FILTER                              |                           |       |       |            |          |
|   3 |    NESTED LOOPS                       |                           |   100 | 11300 |   258   (0)| 00:00:04 |
|   4 |     NESTED LOOPS                      |                           |   100 | 11300 |   258   (0)| 00:00:04 |
|*  5 |      TABLE ACCESS BY INDEX ROWID      | WORKBENCH_MES_REL         |   100 |  6800 |    58   (0)| 00:00:01 |
|*  6 |       INDEX RANGE SCAN                | IND_WMR_RECIPIENT_ID_0905 |   128 |       |     4   (0)| 00:00:01 |
|*  7 |      INDEX UNIQUE SCAN                | PK_WORKBENCH_MES10        |     1 |       |     1   (0)| 00:00:01 |
|*  8 |     TABLE ACCESS BY GLOBAL INDEX ROWID| WORKBENCH_MES             |     1 |    45 |     2   (0)| 00:00:01 |

-------------------------------------------------------------------------------------------------------------------

-------------------------------------------------------------------------------------------------------------
| Id  | Operation                   | Name                  | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |                       |       |       |       |   161K(100)|          |
|   1 |  SORT AGGREGATE             |                       |     1 |   113 |       |            |          |
|*  2 |   FILTER                    |                       |       |       |       |            |          |
|*  3 |    HASH JOIN                |                       |   122K|    13M|  9544K|   161K  (1)| 00:32:17 |
|*  4 |     TABLE ACCESS FULL       | WORKBENCH_MES_REL     |   122K|  8111K|       |  46750  (1)| 00:09:21 |
|   5 |     PARTITION RANGE ITERATOR|                       |  2614K|   112M|       |   107K  (1)| 00:21:25 |
|*  6 |      TABLE ACCESS FULL      | WORKBENCH_MES         |  2614K|   112M|       |   107K  (1)| 00:21:25 |

-------------------------------------------------------------------------------------------------------------

Start diagnosis:
1. The first impression is the index of the two tables is not lost. Because RECIPIENT_ID selectivity is good. Check out the tables, indexes are.
COUNT 2.Select (. 1) from WORKBENCH_MES_REL recipient_id = WHERE '83DB7DD7505B4C90831717AB18881C69';
  SELECT COUNT (. 1) from WORKBENCH_MES_REL recipient_id = WHERE '83DB7DD7505B4C90831717AB18881C69' and IS_READ = 'N';
  query the two SQL result is the same, indicating that the user is substantially do not read the message.
3. problems found. The user basically do not see unread messages, leading to more and more data before taking the index or in the choice of a full assessment of the table, CBO evaluate less data left index ,
as the amount of data increases, CBO prefer take the whole table .

CBO is the abbreviation for Cost-Based Optimization, Chinese called "cost-based optimization."
The Oracle optimizer There are two ways to optimize, optimize the way that is rule-based (Rule-Based Optimization, referred to as RBO)
and cost-based optimization approach (Cost-Based Optimization, referred to as CBO),
in Oracle8 and later, Oracle strongly recommend using CBO's way.

]

Interim solution:
the unread messages a month ago are set to read, recipient and whether the message has been read two fields are indexed and generate histograms.
ON WORKBENCH_MES_REL index IND_WMR_RID_ISREAD Create (recipient_id, IS_READ) NOLOGGING;
Exec dbms_stats.gather_table_stats (User, 'WORKBENCH_MES_REL', Cascade => to true, Degree =>. 8, the method_opt => 'the FOR ALL the COLUMNS the FOR SIZE skewonly the COLUMNS (recipient_id, IS_READ)' , no_invalidate => FALSE);

Deep thinking:
this feature while doing anyway, obviously not used, a large number of users do not have the habit of viewing unread messages. Will you read unread messages you five years ago ?
The need to optimize design:
1. retain only the most recent year the news, because five years has accumulated tens of millions of messages, check this table does not add conditions, it is easy out performance problems.
2. Before a month unread messages, the default mark it as read, because of the loss of effectiveness.
3. User carte menu will query this SQL, instead put the query results in the user's session inside, effective during the session did not have to search the database, of course, also at the expense of effective. The reason for this is that most users do not have the habit to see unread messages, the data obtained from the analysis.
----------------
Disclaimer: This article is CSDN blogger original article "Shenzhen gg" and follow CC 4.0 BY-SA copyright agreement, reproduced, please attach the original source and this link statement.
Original link: https: //blog.csdn.net/stevendbaguo/article/details/79287942

 

Guess you like

Origin www.cnblogs.com/softidea/p/11460624.html