I got a solution maybe
step 1:
mysql explain select * from users;
++-+---+--+---+--+-+--+--+---+
| id | select_type | table | type | possible_keys | key | key_len |
ref | rows | Extra |
Alex
Thank you for the advice.
Probably, we will put index (key) on both columns.
Thanks,
Yu
Alex Schaft さんは書きました:
On 2012/05/24 07:37, Alex Schaft wrote:
You are selecting a record based on the value of data_id and
thold_enabled, but don't have an index on either? Add an index for both.
If
Johnny
Thank you for the reply.
Second, make sure your Innodb buffer pool is allocating as much ram as
possible. I'd even go as far as adding another 8gb of ram to the
server. The buffer pool setting is going to give you the best
performance increase.
The problem is mainly on MyISAM engine.
Hi All,
I need architectural help for our requirement,
We have nearly 50 data centre through out different cities from these data
center application connect to central database server currently, there are
conectivity and nework flcutions issues for different data center, so we comeup
with
is the central database server just ONE server, to which all your 50 data
center app connects
On Thu, May 24, 2012 at 2:47 PM, Anupam Karmarkar
sb_akarmar...@yahoo.comwrote:
Hi All,
I need architectural help for our requirement,
We have nearly 50 data centre through out different cities
A few questions:
which is more or a problem: network outages, network capacity or query latency?
When you say near real-time do you need transactional consistent view on all
49 servers or can some lag be tolerated?
Can any one of the 49 local servers potentially update/delete the same rows or
Dear Nigel,
Thank for reply..
See my comments below
--Anupam
From: Nigel Wood nw...@plus.net
To: Anupam Karmarkar sb_akarmar...@yahoo.com; mysql@lists.mysql.com
mysql@lists.mysql.com
Sent: Thursday, 24 May 2012 3:35 PM
Subject: RE: Architectural Help
A
Maybe.
1. The Rows is approximate, so you could over-shoot or under-shoot the end of
the table.
2. OFFSET (limit $r,1) still has to scan $r rows.
3. SELECT * with an OFFSET will read the entire rows. SELECT `foo`, where
`foo` is indexed, but not the InnoDB PRIMARY KEY, will scan only the
For my propouses aprox is fine. I guess for others it doesnt
El may 24, 2012 9:59 a.m., Rick James rja...@yahoo-inc.com escribió:
Maybe.
1. The Rows is approximate, so you could over-shoot or under-shoot the
end of the table.
2. OFFSET (limit $r,1) still has to scan $r rows.
3. SELECT *
Thanks. I got tired of answering the same questions about buffer_pool and
key_buffer over and over on forums.mysql.com; now I just point people at that
page.
INT(1) and INT(50) are identical -- and take 4 bytes. See TINYINT, BIGINT,
etc. Also, UNSIGNED is probably wanted in more places than
I deal with dozens of systems, all doing cross-country or cross-ocean
replication. The only viable approach (that we have deployed in production) is
* Dual-master, single writer -- That is, all 49 clients write to one machine
* The two masters are geographically separate.
* Failover involves
11 matches
Mail list logo
