Hi,
Is there any performance toolds about UPDATE/INSERT querys?
I want to monitor the UPDATE/INSERT performance, check out if there's any
performance bottleneck, for example:
slow INSERT/UPDATE
more I/O where execute INSERT
Regards
Thanks
J.W
On Thu, Sep 22, 2011 at 3:11 PM, Hassan Schroeder <
hassan.schroe...@gmail.com> wrote:
> On Thu, Sep 22, 2011 at 11:51 AM, Hank wrote:
> > Like I said, the problem is not just one particular SQL statement. It is
> > several dozen statements operating on tables with several hundred million
> > rec
do u have index on dest,key
On Fri, Sep 23, 2011 at 12:21 AM, Hank wrote:
>
> Like I said, the problem is not just one particular SQL statement. It is
> several dozen statements operating on tables with several hundred million
> records. The problem is that I am finding that when I use LOCK TAB
Your outer query "select cpe_mac,max(r3_dt) from rad_r3cap", is doing a full
table scan, you might want to check on this and use a "WHERE" condition to
use indexed column
On Fri, Sep 23, 2011 at 12:14 AM, supr_star wrote:
>
>
> I have a table with 24 million rows, I need to figure out how to op
Like I said, the problem is not just one particular SQL statement. It is
several dozen statements operating on tables with several hundred million
records. The problem is that I am finding that when I use LOCK TABLES,
these queries run slower (please read my ORIGINAL post with all this
information
;>>> 2011/09/22 13:08 -0400, Jerry Schwartz
The user forum: it has many experienced users, some beta testers, and
(because the product is used world-wide) a response time measured in hours.
What it doesn't have is any presence from the company.
Is n't that what companies nowadays w
I have a table with 24 million rows, I need to figure out how to optimize a
query. It has to do with mac addresses and radius packets - I want to see the
# of connections and the min/max date. So I basically want all this data:
select cpe_mac,count(*) c,min(r3_dt) mindt,max(r3_dt) maxdt, m
May be if u can let the audience know a sip-net of ur sql, some can help u
On Thu, Sep 22, 2011 at 11:43 PM, Hank wrote:
>
> Sorry, but you do not understand my original issue or question.
>
> -Hank
>
>
>
> On Thu, Sep 22, 2011 at 2:10 PM, Ananda Kumar wrote:
>
>> No,
>> Use a cursor(select to
Sorry, but you do not understand my original issue or question.
-Hank
On Thu, Sep 22, 2011 at 2:10 PM, Ananda Kumar wrote:
> No,
> Use a cursor(select to be used in where condition of update
> stmt), loop through it for each update.
>
> regards
> anandkl
>
>
> On Thu, Sep 22, 2011 at 11:36 PM
No,
Use a cursor(select to be used in where condition of update
stmt), loop through it for each update.
regards
anandkl
On Thu, Sep 22, 2011 at 11:36 PM, Hank wrote:
>
> Actually, that would be orders of magnitude slower.
>
> I'm using MYISAM tables, so there's no commit.
>
>
>
>
> On Thu, S
Actually, that would be orders of magnitude slower.
I'm using MYISAM tables, so there's no commit.
On Thu, Sep 22, 2011 at 1:48 PM, Ananda Kumar wrote:
> Hi,
> Why dont u use a stored proc to update rows ,where u commit for every 1k or
> 10k rows.
> This will be much faster than ur individ
Hi,
Why dont u use a stored proc to update rows ,where u commit for every 1k or
10k rows.
This will be much faster than ur individual update stmt.
regards
anandkl
On Thu, Sep 22, 2011 at 8:24 PM, Hank wrote:
> That is what I'm doing. I'm doing a correlated update on 200 million
> records. One U
That's a great attitude. I always appreciate it when a support organization
listens to users. I've been on both sides of the fence, and I always hated it
when there //was// a fence.
One thing I always favored, again as both a user and as a tech support
professional, was a public list of known b
That is what I'm doing. I'm doing a correlated update on 200 million
records. One UPDATE statement.
Also, I'm not asking for a tutorial when not to use LOCK TABLES. I'm trying
to figure out why, despite what the documentation says, using LOCK TABLES
hinders performance for large update statements
Even for MyISAM tables, LOCK TABLES is not usually the best solution
for increasing performance. When there is little to no contention,
LOCK TABLES doesn't offer much value.
MyISAM works best when you can get more work done in a statement:
Instead of executing a bunch of insert statements,
This comment has me intrigued:
On 9/21/2011 17:50, John Daisley wrote:
Partitioning is available in the community edition and has been for a
while now. Support is the only real difference and since Oracle took
over the support available in the community is usually faster and better
than you get
Thanks for your reply. I failed to mention that these are MYISAM tables, so
no transactions. And like I said, this is not a production box nor is there
any application running, so there's no contention for the tables being
locked. I'm trying to update a database design on two tables with 200
mil
17 matches
Mail list logo
