Hi,
Your query have to access all rows in `myTable`, thus MySQL optimizer
guesses "reading sequentially is faster than working through an
index".
http://dev.mysql.com/doc/refman/5.6/en/mysql-indexes.html
The case of not using index,
* Reading whole myTable.MYD sequentially
* Sorting
Hi,
Can someone perhaps assist with the below... I'm not sure at all why my
index aren't being used for the ORDER BY. Currently some 443K records in
the table, but this will grow to a good few million. I simply cannot,
afford a filesort.
mysql> SELECT COUNT(*)
Got it;
Thanks!
Zhigang
-Original Message-
From: Hartmut Holzgraefe [mailto:hart...@skysql.com]
Sent: Thursday, September 11, 2014 1:44 PM
To: mysql@lists.mysql.com
Subject: Re: index collate
On 09/11/2014 05:55 AM, Zhigang Zhang wrote:
> The “CREATE INDEX Syntax” can not assig
On 09/11/2014 05:55 AM, Zhigang Zhang wrote:
> The “CREATE INDEX Syntax” can not assign a collation.
>
> What collation to use to create a index on a column?
The collation used for an index on a textual column is
the columns collation itself.
You can't choose a different col
I have a question.
The “CREATE INDEX Syntax” can not assign a collation.
What collation to use to create a index on a column?
Thanks
Zhigang.
Thanks to all,
Best Regards,
Geetanjali Mehra
Senior Oracle and MySQL DBA Corporate Trainer and Database Security
Specialist
On Fri, Aug 29, 2014 at 11:59 AM, Hartmut Holzgraefe
wrote:
> On 08/29/2014 08:15 AM, geetanjali mehra wrote:
> > But after doing *optimize table*, the value inside
> >
On 8/29/2014 5:51 AM, Johan De Meersman wrote:
Senior Oracle and MySQL DBA Corporate Trainer and Database Security
Am I the only one worried about that line, then?
yes.
I welcome help from anyone willing. Expertise and willingness
both are important.
--bill
--
MySQL General Mailing Li
> Senior Oracle and MySQL DBA Corporate Trainer and Database Security
Am I the only one worried about that line, then?
--
Unhappiness is discouraged and will be corrected with kitten pictures.
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:htt
On 08/29/2014 08:15 AM, geetanjali mehra wrote:
> But after doing *optimize table*, the value inside
> data_free is still the same. If there is no change in the value of
> data_free, then what *optimize table* does here?
Without seeing actual values I can only give an educated
guess:
* If you ar
llo Geetanjali,
>
>
> On 8/26/2014 1:11 AM, geetanjali mehra wrote:
>
>> Hello to all,
>>
>> I want to know whether my innodb index is fragemented. Is it possible to
>> know?
>>
>> Best Regards,
>> Geetanjali Mehra
>> Senior Oracle and MySQL DBA Cor
Hello Geetanjali,
On 8/26/2014 1:11 AM, geetanjali mehra wrote:
Hello to all,
I want to know whether my innodb index is fragemented. Is it possible to
know?
Best Regards,
Geetanjali Mehra
Senior Oracle and MySQL DBA Corporate Trainer and Database Security
Specialist
Just like every other
Hello to all,
I want to know whether my innodb index is fragemented. Is it possible to
know?
Best Regards,
Geetanjali Mehra
Senior Oracle and MySQL DBA Corporate Trainer and Database Security
Specialist
Hi Anupam,
We
are keep on getting deadlock due to index locking, there is index on
FLAG, we can allow phantom read in session 1, we tried with READ
COMMITTED but still same, I think issue with next-key locking.
Did you try setting binlog-format=ROW as well?
I have a brief explanation of
;
COMMIT;
SESSION 2:
UPDATE XYZ SET FLAG=1 WHERE ID = 2;
We
are keep on getting deadlock due to index locking, there is index on
FLAG, we can allow phantom read in session 1, we tried with READ
COMMITTED but still same, I think issue with next-key locking.
If i do following in SESSION 1 would that
;
COMMIT;
SESSION 2:
UPDATE XYZ SET FLAG=1 WHERE ID = 2;
We are keep on getting deadlock due to index locking, there is index on FLAG,
we can allow phantom read in session 1, we tried with READ COMMITTED but still
same, I think issue with next-key locking.
If i do following in SESSION 1 would that
-Original Message-
> From: Dolan Antenucci [mailto:antenucc...@gmail.com]
> Sent: Monday, August 12, 2013 10:26 AM
> To: mysql@lists.mysql.com
> Subject: MyISAM index missing rows
>
> Hi Everyone,
>
> I have a MyISAM table with 25 billion rows (structure: score float&
Hi Everyone,
I have a MyISAM table with 25 billion rows (structure: ), and after I create an index on id1, certain rows can no
longer be found.
I've posted a detailed summary of my problem at dba.stackexchange.com, but
haven't had success with finding a solution thus far. Here's
The level is the height of a B-tree table or a B-tree index in mysql 5.6.
My question is how to get the height(blevel) of a B-tree table or a B-tree
index in mysql 5.6?
Thanks.
In oracle database,we can use the following statement to query the blevel of a
index
select index_name,blevel
Or maybe the number of levels in the BTree?
Rule of Thumb: logarithm base 100
> -Original Message-
> From: Hartmut Holzgraefe [mailto:hart...@skysql.com]
> Sent: Monday, July 08, 2013 6:38 AM
> To: mysql@lists.mysql.com
> Subject: Re: how to get the levels of a table or a
On 08.07.2013 04:23, 李炜(平安科技数据库技术支持部) wrote:
> how to get the levels of a table or a index in Mysql 5.6?
Level? What is level supposed to be in that context?
Cardinality? Or something completely different?
/me confused ...
--
Hartmut Holzgraefe
Principal Support Engineer (EMEA)
SkySQL
Hi
how to get the levels of a table or a index in Mysql 5.6?
thanks
The information in this email is confidential and may be legally privileged. If
you have
Sorry, I can't address your specific question, but I have several other tips,
some of which may save a lot of space...
USING HASH -- ignored; presumably BTree is used instead.
What Version of MySQL? 5.5(?) can drop an InnoDB (only?) index live.
BTrees sometimes grow after any sort of
/db/mysql-srv/bin.03
[root@srv-rhsoft:~]$ cat /etc/my.cnf | grep bin
log-bin = /mnt/data/db/mysql-srv/bin.log
log-bin-index = /mnt/data/db/mysql-srv/bin.index
Am 27.03.2013 20:25, schrieb Arnold:
> There are files beginning with 1..
There are files beginning with 1.. The sequence number is
01 to 15. A new file is created every time MySQL is restarted. The
1.index file contains a list of these files. One thing that I have done is
when I was hardening the security we stopped MySQL and moved the data directory
to
Am 27.03.2013 19:53, schrieb Arnold:
> What are the *.index files in the MySQL Data directory? I notice a new one
> is created every time that MySQL is stopped and restarted. My Data directory
> is not in the default location so does that have anything to do with it?
maybe a "
What are the *.index files in the MySQL Data directory? I notice a new one is
created every time that MySQL is stopped and restarted. My Data directory is
not in the default location so does that have anything to do with it?
Thanks,
Sandra Arnold
Data Warehouse Administrator
MartinFederal
Hello,
Well, you have just invented what is known as index organized tables. The
MyISAM engine does not implement those.
If it did, it would have to deal with quite a few circumstances unique to IOTs.
One such circumstance is degradation
of efficiency with the increase of record length
MyISAM can't do this but innodb can. If you change to an innodb table
and define your index as the primary key then row data is clustered
with the primary key. This means there is no additional storage
overhead for the primary key because it is just the row data. This
will break down if you d
Am 24.11.2012 22:02, schrieb Hank:
> Hello everyone,
>
> I know this is a longshot, but is there any way to eliminate the MYD
> file for a table that has a full covering index? The index is larger
> than the datafile, since it contains all the records in the datafile,
> plu
1. Secondary indexes (but not the PRIMARY KEY) requires additional disk space.
A secondary index implicitly includes copies the field(s) of the PRIMARY KEY;
this is how it can get to the actual data row. Finding a row via a secondary
key involves two BTree lookups -- one in the secondary
Innodb stores it's indexes internally in the datafile; they do consume
storage, but that space is shared with the data.
innodb_per_file will, in most cases, enhance performance in a
high-concurrency environment. It also can simplify administration,
and help limit your liabilities in the event of
hi lists 1. does the indexes require additional storage other than
the table space storage. 2. is there any performance difference
will be there, if we go for innodb_file_per_table.
Normal
0
false
false
false
EN-US
X-NONE
AR-SA
That's exactly what I thought when reading Michael's email, but tried
anyways, thanks for clarification :)
2012/10/16
> 2012/10/16 12:57 -0400, Michael Dykman
> your now() statement is getting executed for every row on the select. try
> ptting the phrase up front
> as in:
> set @ut= u
2012/10/16 12:57 -0400, Michael Dykman
your now() statement is getting executed for every row on the select. try
ptting the phrase up front
as in:
set @ut= unix_timestamp(now())
and then use that in your statement.
Quote:
Functions that return the current date or time each are
do Caldi; mysql@lists.mysql.com
> Subject: Re: Can I measure the use of index?
>
> For the record mariadb also has table and index statistics. Including
> statistics on temporary tables.
>
> On Mon, Oct 15, 2012 at 8:34 PM, Lixun Peng
> wrote:
> > Hi,
> >
> > I
Interesting thought, but I get the same result.
# Query_time: 0.001769 Lock_time: 0.001236 Rows_sent: 0 Rows_examined: 0
use kannel;
SET timestamp=1350413592;
select * from send_sms FORCE INDEX (priority_time) where time<=@ut order by
priority limit 0,11;
the MySQL i'm using is 5.5
ET timestamp=1350389078;
SELECT sql_id, momt, sender, receiver, udhdata, msgdata, time, smsc_id,
service, account, id, sms_type, mclass, mwi, coding, compress, validity,
deferred, dlr_mask, dlr_url, pid, alt_dcs, rpi, charset, boxc_id, binfo,
meta_data, task_id, msgid FROM send_sms_test FORCE INDEX (pr
oxc_id, binfo,
meta_data, task_id, msgid FROM send_sms_test FORCE INDEX (priority_time)
WHERE time <= UNIX_TIMESTAMP(NOW()) ORDER by priority LIMIT 0,50;
2012/10/16 Shawn Green
> On 10/15/2012 7:15 PM, spameden wrote:
>
>> Thanks a lot for all your comments!
>>
>> I did
On 10/15/2012 7:15 PM, spameden wrote:
Thanks a lot for all your comments!
I did disable Query cache before testing with
set query_cache_type=OFF
for the current session.
I will report this to the MySQL bugs site later.
First. What are all of your logging settings?
SHOW GLOBAL VARIAB
For the record mariadb also has table and index statistics. Including
statistics on temporary tables.
On Mon, Oct 15, 2012 at 8:34 PM, Lixun Peng wrote:
> Hi,
>
> If you are using Percona Server, you can use this query:
>
> SELECT DISTINCT s.table_schema,
>
knows how can I log or measure the index use ?
>
> http://www.percona.com/doc/percona-toolkit/2.1/pt-index-usage.html
>
> - Perrin
>
> --
> MySQL General Mailing List
> For list archives: http://lists.mysql.com/mysql
> To unsubscribe:http://lists.mysql.com/mysql
>
y uses an INDEX?
>
>
>
> That _may_ be worth a bug report.
>
> ** **
>
> A _possible_ answer... EXPLAIN presents what the optimizer is in the mood
> for at that moment. It does not necessarily reflect what it was in the
> mood for when it ran the query.
&
Ø My initial question was why MySQL logs it in the slow log if the query uses
an INDEX?
That _may_ be worth a bug report.
A _possible_ answer... EXPLAIN presents what the optimizer is in the mood for
at that moment. It does not necessarily reflect what it was in the mood for
when it ran
I don't fully understand Handler numbers, either. But note the vast difference
in Handler_read_next, as if the second test had to read (sequentially scan) a
lot more stuff (in the index or the data).
Summary:
INDEX(time, priority) -- slower; bigger Handler numbers; shorter ke
f I turn it off - it's all fine
My initial question was why MySQL logs it in the slow log if the query uses
an INDEX?
And why it's not logging if I create an INDEX (time, priority) (but in the
query there is FORCE INDEX (priority,time) specified, so MySQL shouldn't
use newly creat
* from send_sms_test FORCE INDEX (time_priority) where
time<=UNIX_TIMESTAMP(NOW()) order by priority;
++-+---+---+---+---+-+--+---+-+
| id | select_type | table | type | possible_keys | key
avoid the bogus 11/22.
* If the CREATE INDEX took only 0.67 sec, I surmise that you have very few rows
in the table?? So this discussion is not necessarily valid in general cases.
* What percentage of time values meet the WHERE? This has a big impact on the
choice of explain plan and performan
st FORCE INDEX (time_priority) where
time<=UNIX_TIMESTAMP(NOW()) order by priority limit 0,13;*
++-+---+---+---+---+-+--+---+-+
| id | select_type | table | type | possible_keys | key
| ke
-gnu on x86_64 ((Percona Server
(GPL), 14.0, Revision 475))
If I check with EXPLAIN MySQL says it would use the index:
mysql> *desc select * from send_sms_test where time<=UNIX_TIMESTAMP(NOW())
order by priority limit 0,11;*
++-+---+---+---+
On Mon, Oct 15, 2012 at 11:24 AM, Carlos Eduardo Caldi
wrote:
> Somebody knows how can I log or measure the index use ?
http://www.percona.com/doc/percona-toolkit/2.1/pt-index-usage.html
- Perrin
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscr
I want to count how many time one index was used during a day, do you now how
to log it to count?
> Date: Mon, 15 Oct 2012 17:27:54 +0200
> From: h.rei...@thelounge.net
> To: mysql@lists.mysql.com
> Subject: Re: Can I measure the use of index?
>
>
>
> Am 15.10.20
Am 15.10.2012 17:24, schrieb Carlos Eduardo Caldi:
>
> Afternoon
>
> Somebody knows how can I log or measure the index use ?
explain select whatever from table where bla=value
signature.asc
Description: OpenPGP digital signature
Afternoon
Somebody knows how can I log or measure the index use ?
Thanks
Carlos
n't have enough details of
your app to explain relevant details.
Do you expect to get more than 1 guid from first query? Multiple rows from
second query?
item_spline needs an index beginning with location_code.
item_detail _might_ benefit from INDEX(guid, sequence).
> -Original Me
ts.mysql.com
> Subject: why this query doesn't use index?
>
> Hello,
>
> can you tell me why my this query doesn't use the index?
>
>
> mysql> explain select * from ipl
On 16/07/2012 17:39, Rick James wrote:
How many rows? If 1K, it does not matter. If 1 billion, we need to
discuss in more detail. Let's assume 1M...
Around 1M in the item_spine table and 10M in item_detail.
Dates should be stored in DATE datatype, which is 3 bytes. Your GUID
is non-standa
ables.)
Let's see the SELECTs that will be hitting the tables. Then we can discuss in
more detail.
> -Original Message-
> From: Mark Goodge [mailto:m...@good-stuff.co.uk]
> Sent: Monday, July 16, 2012 8:09 AM
> To: mysql
> Subject: Unique index - opinions sought
I have a MySQL table (call it, say, item_spine) which contains three
fields which, together, form a unique key. These three fields are a
guid, a start date and an end date. The guid is alphanumeric (a
fixed-length six characters) and the dates are ISO format dates
(-MM-DD).
I also have an
t; -Original Message-
> From: Jeffrey Grollo [mailto:grol...@gmail.com]
> Sent: Tuesday, July 10, 2012 2:50 PM
> To: mysql@lists.mysql.com
> Subject: Composite Index Usage in Joins
>
> Hi,
>
> I'm attempting to optimize a join and am having a difficult time usin
> can you tell me why my this query doesn't use the index?
>
>
> mysql> explain select * from iploc where 1902800418 between start_ip
> and end_ip;
Hazarding a very quick guess: if this table is what I think it is (NON-
overlapping IP ranges + (geo)location), you mig
Hello,
can you tell me why my this query doesn't use the index?
mysql> explain select * from iploc where 1902800418 between start_ip
and end_ip;
++-+---+--+---+--+-+--+---+-+
| id | select_type | table | type | possi
On Wed, Jul 11, 2012 at 5:30 PM, Sergei Petrunia wrote:
> I can provide a refutation. Ability to make a combined index access of
>
> 1. Equality with a non-constant: t.sec_id= p.sec_id
> 2. non-equality comparison with constants, trade_time IN ('2012-07-01',
> &
Thanks for the guidance and references, Shawn.
On Wed, Jul 11, 2012 at 3:37 PM, Shawn Green wrote:
>
> Ranged scans only happen for the last portion of an index being used. OR
> queries (or those using IN) can also only be applied to the last part of an
> index search. This means tha
On Tue, Jul 10, 2012 at 05:50:07PM -0400, Jeffrey Grollo wrote:
> Hi,
>
> I’m attempting to optimize a join and am having a difficult time using
> multiple columns from a composite index. The second column of the composite
> key is being used when tested for equality, but not fo
On 7/10/2012 5:50 PM, Jeffrey Grollo wrote:
Hi,
I’m attempting to optimize a join and am having a difficult time using
multiple columns from a composite index. The second column of the composite
key is being used when tested for equality, but not for IN or BETWEEN
criteria.
As an example, say
Hi,
I’m attempting to optimize a join and am having a difficult time using
multiple columns from a composite index. The second column of the composite
key is being used when tested for equality, but not for IN or BETWEEN
criteria.
As an example, say that I’m searching two tables: portfolio and
On 31 Oct 2011, at 08:46, Jeff Pang wrote:
> Hello,
>
> I have a question that, if I add the index to the table in slave, but
> don't do it in master, will it make problems?
Jeff,
I manage some big data here and this is my preferred strategy - shard the
workload in diff
will differ from the original master and you might notice a
performance difference as a result.
Hth
Andrew
On Oct 31, 2011 7:47 AM, "Jeff Pang" wrote:
> Hello,
>
> I have a question that, if I add the index to the table in slave, but
> don't do it in master, will i
Hello,
I have a question that, if I add the index to the table in slave, but
don't do it in master, will it make problems?
Thanks.
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
- Original Message -
> From: "Tompkins Neil"
> Thanks for the information. One final question in what ways should we
> use EXPLAIN EXTENDED statement to help improve our query
> performance.
Explain is your friend. You should listen to it :-)
It gives a nice idea of how the database i
ends on the data and usage, but probably I'd go for a index(a,b) &
> > index(b,a) if reads heavily outnumber writes. As index(a) is covered
> > by index(a,b), and index(b) by index(b,a), we don't need to add those,
> > which saves time on modifications.
>
> I&
- Original Message -
> From: "Rik Wasmus"
>
> Depends on the data and usage, but probably I'd go for a index(a,b) &
> index(b,a) if reads heavily outnumber writes. As index(a) is covered
> by index(a,b), and index(b) by index(b,a), we don't n
> In this instance would you create four indexes key(a) key(b) key(a,b) key
> (b,a) ? Or is the decision based on the query response time ?
Depends on the data and usage, but probably I'd go for a index(a,b) &
index(b,a) if reads heavily outnumber writes. As index(a) is covere
No single answer here, test with your data and
> you'll have the results.
>
> If you need it often, I'd go for the combined index & let MySQL do the work,
> which is probably fastest.
> --
> Rik Wasmus
>
> --
> MySQL General Mailing List
> For list
ated indexes on a & b, it depends on the data, the
distribution of values, etc. No single answer here, test with your data and
you'll have the results.
If you need it often, I'd go for the combined index & let MySQL do the work,
which is probably fastest.
--
Rik Wasmus
--
ng for anything that matches 'b' for an index (a,b)
requires
a full scan as you don't know 'a', likewise searching for 'a' in an
index
(b,a) requires a full scan. See it as looking through a phonebook
trying to
locate someone by first- rather then lastname. It's i
On 2011/10/11 02:22 PM, Rik Wasmus wrote:
Just to clarify having key indexes of (a,b) or (b,a) have no difference ?
They DO.
See it as lookup table which starts with 'a' in the first case, and 'b' in the
second one. Looking for anything that matches 'b' for an in
> Just to clarify having key indexes of (a,b) or (b,a) have no difference ?
They DO.
See it as lookup table which starts with 'a' in the first case, and 'b' in the
second one. Looking for anything that matches 'b' for an index (a,b) requires
a full sca
The difference is based on the relative frequency of queries where a is
important vs. where b is important. Either way, what will happen is that the
index scan will isolate the first item mentioned, then scan the result set
to isolate the second term.
e.g.
SELECT * FROM someTable WERE a
> B, or an order by A, B, would single column indexes on A and B suffice
>> or would performance on the order by query be improved by an index on
>> A,B?
>
> Depends on usage :-)
>
> key (a, b) is good for "where a=.." or "where a=.. and b=.."
> ke
- Original Message -
> From: "Alex Schaft"
>
> If you have a table with columns A & B, and might do a where on A or
> B, or an order by A, B, would single column indexes on A and B suffice
> or would performance on the order by query be improved by an inde
If you have a table with columns A & B, and might do a where on A or B,
or an order by A, B, would single column indexes on A and B suffice or
would performance on the order by query be improved by an index on A,B?
Thanks
--
MySQL General Mailing List
For list archives:
- Original Message -
> From: "Dave Dyer"
>
> It depends on if you want the forest or the trees. A frequently
> executed query asks for just the robots. An index is an efficient way to
> select 6 of 20,000. As for why the rest are null, null is just a a
>
At 12:43 AM 8/30/2011, mysql-plain-digest-h...@lists.mysql.com wrote:
>Not useful to add an index for that. I also wonder why the value is null
>(meaning: unknown, not certain) for almost all records.
It depends on if you want the forest or the trees. A frequently executed
query asks fo
thanks . i dropped the primary key , and it still didn't use the index .
when i dropped the index `range`, and add two indexes `start` and
`end` . it picks up the index , but it still used more seconds than
using no
index with `start` and `end` indexed as one --`range`.
2011/7/28 Joh
[Note to self, reply to mailinglist, not to author ;) ]
> i found a strange problem . when i using index for 'select' , i
> got a slower result than without index .
> i have a tabe :
> create table geo_query (
> `id` int(10) unsigne
The optimizer is right, you are wrong, as simple as that :-)
between [field1] and [field2] cannot use indices, as your primary
reference is a constant, not a field. Rewrite that to "start >= 1988778880 and
end <= 1988778880" and the optimizer should pick up the index.
Index
Hi
i found a strange problem . when i using index for 'select' , i
got a slower result than without index .
i have a tabe :
create table geo_query (
`id` int(10) unsigned not null auto_increment ,
`start` bigint(20) unsigned not null ,
Hey guys,
I'm working on some performance tuning tasks and realized that there was a
missing index in one of my tables so sure enough I added it on my local
database with the following sql statement:
mysql> create index id_idx on users(id);
Query OK, 972064 rows affected (36.77 sec)
I'm busy creating an index on a 518505 record table on a single column
> which is now taking about 2 hours on the copy to tmp table process
>
> The server is a 2gig ram Intel(R) Xeon(TM) CPU 3.00GHz running on a
> hardware raid 5. The inno config was left as a standard insta
Hi,
I'm busy creating an index on a 518505 record table on a single column
which is now taking about 2 hours on the copy to tmp table process
The server is a 2gig ram Intel(R) Xeon(TM) CPU 3.00GHz running on a
hardware raid 5. The inno config was left as a standard install from
my-m
I am trying to optimize a query that uses a group by on a varchar(255)
column. The column has a large enough cardinality that a 10 character
partial index uniquely covers over 99% of all values. I was hoping
that this partial index would be able to help with the group by
(though obviously not as
We are currently evaluating the merge engine. Right now we create and
preload several index caches.
But what is the best way to approach this with a merged table? Do I
create a single index cache and assign all of the shards to it?
Or do I create a separate index cache for each shard?
I
', SUM(if (px_orders.sales_orders.order_completed_date >=
DATE_SUB(CURDATE( ),INTERVAL DAYOFYEAR(CURDATE( ))-1
DAY),px_orders.sales_order_products.paid_amount,0)))
as ytd
FROM
px_orders.sales_order_products LEFT JOIN px_orders.sales_orders
ON px_orders.sales_order_products.order_id = px_orders.
4 days to drop Index
Hi.
I think you should upgrade your hardware and adjust your mysqld's
parameters. Then your job will be fine.
David Yeung, In China, Beijing.
My First Blog:http://yueliangdao0608.cublog.cn
My Second Blog:http://yueliangdao0608.blog.51cto.com
My Msn: yueliangdao0...@gmail
12/23 Adarsh Sharma
> Dear all,
>
> Things becomes too lazy when it takes too much time.
>
> I am suffering from this problem when droping index of size 17.7 GB on a
> table of size 24.7 GB.
> This table have some more indexes of different sizes.
> It takes near about 4 da
Dear all,
Things becomes too lazy when it takes too much time.
I am suffering from this problem when droping index of size 17.7 GB on a
table of size 24.7 GB.
This table have some more indexes of different sizes.
It takes near about 4 days to drop the index.
Can anyone Please guide me
Hi Johan,
On Sun, Dec 19, 2010 at 7:11 PM, Johan De Meersman wrote:
> You can't query the index directly, but if you select only fields that are
> in the index, no table lookups will be performed - this is called a covering
> index.
>
Great.. Thanks for the confirmation.
On Sun, Dec 19, 2010 at 3:19 AM, Feris Thia <
milis.datab...@phi-integration.com> wrote:
> Hi Everyone,
>
> Is there a way to query values stored in our index instead of using "group
> by" selection which will produce same results ?
>
You can't query the in
Hi Everyone,
Is there a way to query values stored in our index instead of using "group
by" selection which will produce same results ?
Please advice..
Regards,
Feris
1 - 100 of 2221 matches
Mail list logo
