Shamim's Diary

Analyzing the slow query log We need to analyze the slow query log in order to identify the queries that impact a system. It does not always have to be the slowest queries that do this, because queries running more frequently with lower execution time (for example, a query that takes 1 seconds to run but runs thousands of times per minute) increase the workload on a system more than really slow queries running with less frequency (for example, a query that takes 60 seconds to run once a month). Really slow queries impact the system throughput, but queries running frequently generate most of the system workload. Eventually, the slow query log grows in size, and the size is too big to analyze by simple inspection. In order to get a big picture on slow queries, MySQL provides a tool named  mysqldumpslow  to display the results in a way that’s easy to analyze. To use this tool, we need to pass the  slow query log  as the parameter, as shown in listing 09. $ my...

Courtesy: VLAD MIHALCEA Introduction JDBC  has long been offering support for  DML  statement batching. By default, all statements are sent one after the other, each one in a separate network round-trip. Batching allows us to send multiple statements in one-shot, saving unnecessary socket stream flushing. Hibernate hides the database statements behind a transactional  write-behind abstraction layer . An intermediate layer allows us to hide the JDBC batching semantics from the persistence layer logic. This way, we can change the JDBC batching strategy without altering the data access code. Configuring Hibernate to support JDBC batching is not as easy as it should be, so I’m going to explain everything you need to do in order to make it work. Testing time We’ll start with the following entity model: The  Post  has a one-to-many association with the  Comment  entity: 1 2 3 4 5 @OneToMany (    ...