I've created a table with 50 million rows on MSSQLServer 2008R2 and MYSQL WorkBench 6.1.
I'm not sure why this query take 16Sec on MySql but 0 Sec on SQL-Server?
SELECT avg(speed) FROM tm where RoadId%5=0 and time%3=0;
-Performance difference exists with different where clauses.
-SQL-Server and MySQL both installed in one machine with 128 GB of Ram and 16 core CPU.
ps: This is script to create table on SQL-Server
CREATE TABLE [dbo].[TM](
[RoadId] [int] NOT NULL,
[Date] [smallint] NOT NULL,
[Time] [tinyint] NOT NULL,
[VType] [tinyint] NOT NULL,
[Speed] [tinyint] NOT NULL,
CONSTRAINT [PK_TM_1] PRIMARY KEY CLUSTERED
(
[RoadId] ASC,
[Date] ASC,
[Time] ASC,
[VType] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
and MySQL:
CREATE TABLE `tm` (
`RoadId` int(11) NOT NULL,
`Date` smallint(6) NOT NULL,
`Time` tinyint(3) unsigned NOT NULL,
`VType` tinyint(3) unsigned NOT NULL,
`Speed` tinyint(3) unsigned NOT NULL,
PRIMARY KEY (`RoadId`,`Date`,`Time`,`VType`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
SQL Server automatically implements parallelism for this type of query, whereas mysql does not. This basically means that SQL will divide up the table scan and analyze rows with multiple threads. I believe mysql requires the data to be partitioned in order to achieve this same functionality.
Related
I have a table in MySQL (InnoDB engine) with 100M records. Structure is as below:
CREATE TABLE LEDGER_AGR (
ID BIGINT(20) NOT NULL AUTO_INCREMENT,
`Booking` int(11) NOT NULL,
`LType` varchar(5) NOT NULL,
`PType` varchar(5) NOT NULL,
`FType` varchar(5) DEFAULT NULL,
`TType` varchar(10) DEFAULT NULL,
`AccountCode` varchar(55) DEFAULT NULL,
`AgAccountId` int(11) DEFAULT '0',
`TransactionDate` date NOT NULL,
`DebitAmt` decimal(37,6) DEFAULT '0.000000',
`CreditAmt` decimal(37,6) DEFAULT '0.000000',
KEY `TRANSACTION_DATE` (`TransactionDate`)
)
ENGINE=InnoDB;
When I am doing:
EXPLAIN
SELECT * FROM LEDGER_AGR
WHERE TransactionDate >= '2000-08-01'
AND TransactionDate <= '2017-08-01'
It is not using TRANSACTION_DATE index. But when I am doing:
EXPLAIN
SELECT * FROM LEDGER_AGR
WHERE TransactionDate = '2000-08-01'
it is using TRANSACTION_DATE index. Could someone explain please?
Range query #1 has poor selectivity. Equality query #2 has excellent selectivity. The optimizer is very likely to choose the index access path when result rows will be < 1% of total rows in table. The backend optimizer is unlikely to prefer the index when result rows will be a large fraction of the total, for example a half or a quarter of all rows.
A range of '2000-08-01' thru '2000-08-03' would likely exploit the index.
cf: mysql not using index?
I have a sql server db keeping our text document datas.
A specific table is keeping thousands of text paragraphs themself, This table suddenly started to respond so lately to update queries abnormally. Sometimes non-complicated basic update query takes 30 - 40 secs. to execute and asp.net application uses this table throws timeout exception.
Select queries last normal as before but update.
Why this happens and what should I do?
Server system is Windows 2008 R2 Standard and MsSql Server 2008 R2
Below's my table meta data.
CREATE TABLE [dbo].[MetinIcerikTablosuCari](
[ID] [int] IDENTITY(1,1) NOT NULL,
[MetinIsimID] [int] NOT NULL,
[MetinIsimID_Eski_1] [int] NULL,
[MetinIsimID_Eski_2] [int] NULL,
[MetinIsimID_Eski_3] [int] NULL,
[MetinIsimID_Eski_4] [int] NULL,
[MetinIsimID_Eski_5] [int] NULL,
[MetinIcindekilerID] [int] NOT NULL,
[SilmeTalebi] [bit] NULL,
[SiraNo] [int] NOT NULL,
[ParagrafMetin] [text] NOT NULL,
[RevizeParagraf] [text] NULL,
[RevizeVarMi] [bit] NULL,
[RevizasyonOnayi] [bit] NULL,
[RevizasyonTarihi] [datetime] NULL,
[RevizasyonSahibiID] [int] NULL,
[RevizasyonOnayTarihi] [datetime] NULL,
[RevizasyonOnaylayanID] [int] NULL,
[RevizasyonSonOnay] [bit] NULL,
[RevizeTuru] [int] NULL,
[ParagrafRevizeIslemJetonu] [nvarchar](50) NULL,
[BaglantiliOrtakRevizeSeriNo] [int] NULL,
[SonOnayTarihi] [datetime] NULL,
[SonOnaylayanID] [int] NULL,
[ParagrafMetin_Eski_1] [text] NULL,
[ParagrafMetin_Eski_2] [text] NULL,
[ParagrafMetin_Eski_3] [text] NULL,
[ParagrafMetin_Eski_4] [text] NULL,
[ParagrafMetin_Eski_5] [text] NULL,
[GirisTarihi] [nvarchar](50) NULL,
[YayinTarihi] [nvarchar](50) NULL,
[ParagrafNot] [nvarchar](max) NOT NULL,
[DipNotTag] [nvarchar](max) NOT NULL,
[MedyaURL] [nvarchar](100) NULL,
[MedyaUrlNot] [nvarchar](max) NOT NULL,
[VersiyonMetin] [int] NULL,
[EtkileyenMetinID] [int] NULL,
[tarih] [nvarchar](max) NULL,
[GuncellemeTarihi] [datetime] NULL,
[NotParagrafi] [bit] NULL,
[YeniParagraf] [bit] NULL,
[MedyaParagrafi] [bit] NULL,
[EslestirmeSilmeOnayID] [int] NULL,
[YargiOnBilgiSayfasi] [bit] NULL,
[BolumParagrafi] [bit] NULL,
[UstParagrafID] [int] NULL,
CONSTRAINT [PK_MetinIcerikTablosuCari] PRIMARY KEY CLUSTERED
(
[ID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
GO
ALTER TABLE [dbo].[MetinIcerikTablosuCari] ADD CONSTRAINT [DF_MetinIcerikTablosuCari_MetinIsimID] DEFAULT ((0)) FOR [MetinIsimID]
GO
ALTER TABLE [dbo].[MetinIcerikTablosuCari] ADD CONSTRAINT [DF_MetinIcerikTablosuCari_MetinIcindekilerID] DEFAULT ((0)) FOR [MetinIcindekilerID]
GO
ALTER TABLE [dbo].[MetinIcerikTablosuCari] ADD CONSTRAINT [DF_MetinIcerikTablosuCari_SiraNo] DEFAULT ((0)) FOR [SiraNo]
GO
ALTER TABLE [dbo].[MetinIcerikTablosuCari] ADD CONSTRAINT [DF_MetinIcerikTablosuCari_ParagrafMetin] DEFAULT ('') FOR [ParagrafMetin]
GO
ALTER TABLE [dbo].[MetinIcerikTablosuCari] ADD CONSTRAINT [DF_MetinIcerikTablosuCari_RevizeTuru] DEFAULT ((1)) FOR [RevizeTuru]
GO
ALTER TABLE [dbo].[MetinIcerikTablosuCari] ADD CONSTRAINT [DF_MetinIcerikTablosuCari_ParagrafNot] DEFAULT ('') FOR [ParagrafNot]
GO
ALTER TABLE [dbo].[MetinIcerikTablosuCari] ADD CONSTRAINT [DF_MetinIcerikTablosuCari_DipNotTag] DEFAULT ('') FOR [DipNotTag]
GO
ALTER TABLE [dbo].[MetinIcerikTablosuCari] ADD CONSTRAINT [DF_MetinIcerikTablosuCari_MedyaUrlNot] DEFAULT ('') FOR [MedyaUrlNot]
GO
ALTER TABLE [dbo].[MetinIcerikTablosuCari] ADD CONSTRAINT [DF_MetinIcerikTablosuCari_NotParagrafi] DEFAULT ((0)) FOR [NotParagrafi]
GO
ALTER TABLE [dbo].[MetinIcerikTablosuCari] ADD CONSTRAINT [DF_MetinIcerikTablosuCari_YeniParagraf] DEFAULT ((0)) FOR [YeniParagraf]
GO
ALTER TABLE [dbo].[MetinIcerikTablosuCari] ADD CONSTRAINT [DF_MetinIcerikTablosuCari_MedyaParagrafi] DEFAULT ((0)) FOR [MedyaParagrafi]
GO
ALTER TABLE [dbo].[MetinIcerikTablosuCari] ADD CONSTRAINT [DF_MetinIcerikTablosuCari_EslestirmeSilmeOnayID] DEFAULT ((0)) FOR [EslestirmeSilmeOnayID]
GO
ALTER TABLE [dbo].[MetinIcerikTablosuCari] ADD CONSTRAINT [DF_MetinIcerikTablosuCari_YargiOnBilgiSayfasi] DEFAULT ((0)) FOR [YargiOnBilgiSayfasi]
GO
ALTER TABLE [dbo].[MetinIcerikTablosuCari] ADD CONSTRAINT [DF_MetinIcerikTablosuCari_BolumParagrafi] DEFAULT ((0)) FOR [BolumParagrafi]
GO
I checked out and executed the update stats sp, but it seems the problem keeps going.
A simple update query like this: update MetinIcerikTablosuCari set ParagrafMetin = '<p>SPK Bültenleri - 2002/34: #media#93640#media#</p>' where ID = 35606 takes 20 - 30 secs or more.
I checked the CPU usage while the query executing, it suddenly picks to appr. 75 - 80%.
I could not determine if it's about lack of server memory or sql uses memory abnormally.
Below is my server hardware specifications:
Windows 2008 R2 Standard - Service Pack1
Processor: Intel Core i5-2400 CPU # 3.1 Ghz
RAM: 8GB
System Type: 64-bit
In addition, could this be kind of lack of updates for Windows Server or MsSql Server 2008 r2
As you haven't provided the execution plan and other necessary details, my assumption is that you might have indexes which are causing slow updates. Indexes helps running SELECT fast but slow down insert and update statements. List out all the indexes (Clustered & Non-Clustered) and then remove unnecessary indexes from your table.
Also, how often do you update statistics? If that is not recently done then run following SP
EXEC Sp_Updatestats;
If above two ways doesn't solve your problem then I recommend you to post table metadata and execution plan.
My new VPN accepts only sql statements with square brackets hence I edited the traditional sql query to:
CREATE TABLE admin (
[id] int(11) NOT NULL AUTO_INCREMENT,
[name] varchar(128) NOT NULL,
[email] varchar(64) NOT NULL,
PRIMARY KEY (id)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=2;
But it shows this error:
Msg 102, Level 15, State 1, Line 1 Incorrect syntax near
'AUTO_INCREMENT'
Basically the server is windows azure and I am using Microsoft SQL server management studio to execute sql queries.
CREATE TABLE [dbo].[admin](
[id] [int](11) IDENTITY(1,1) NOT NULL,
[name] [varchar](128) NULL,
[email] [varchar](64) NULL,
CONSTRAINT [PK_admin] PRIMARY KEY CLUSTERED
(
[id] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
In sql server should be created auto increment to use IDENTITY not AUTO_INCREMENT. Like this
CREATE TABLE admin (
[id] int(11) IDENTITY(1,1) NOT NULL ,
[name] varchar(128) NOT NULL,
[email] varchar(64) NOT NULL,
PRIMARY KEY (id)
)
More detail to refer this link http://www.w3schools.com/sql/sql_create_table.asp
CREATE TABLE [dbo].[admin](
[ID] [int]IDENTITY(1,2) NOT FOR REPLICATION NOT NULL,
[name] [char](128) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL,
[email] [varchar](64) NOT NULL,
PRIMARY KEY CLUSTERED
(
[ID] ASC
)WITH (IGNORE_DUP_KEY = OFF) ON [PRIMARY]
) ON [PRIMARY]
I have the following SQL Server Create Script. Can anyone help me convert this to MySQL.
I'm not sure what the bit defining the Primary Key is doing.
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
SET ANSI_PADDING ON
GO
CREATE TABLE IF NOT EXISTS `webdb`.`UserSessions`(
UniqueID VARCHAR(50) NOT NULL,
UserID VARCHAR(255) NOT NULL,
TokenExpires DATETIME NOT NULL,
LastSeen DATETIME NOT NULL,
LoggedOut bit NOT NULL,
CONSTRAINT [PK_EndedSessions] PRIMARY KEY CLUSTERED
(
UniqueID ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
GO
SET ANSI_PADDING OFF
GO
CREATE TABLE IF NOT EXISTS `webdb`.`UserSessions`
(
UniqueID VARCHAR(50) NOT NULL PRIMARY KEY,
UserID VARCHAR(255) NOT NULL,
TokenExpires DATETIME NOT NULL,
LastSeen DATETIME NOT NULL,
LoggedOut bit NOT NULL
);
So basically I have three tables:
CREATE TABLE `cdIPAddressToLocation` (
`IPADDR_FROM` int(10) unsigned NOT NULL COMMENT 'Low end of the IP Address block',
`IPADDR_TO` int(10) unsigned NOT NULL COMMENT 'High end of the IP Address block',
`IPLOCID` int(10) unsigned NOT NULL COMMENT 'The Location ID for the IP Address range',
PRIMARY KEY (`IPADDR_TO`),
KEY `Index_2` USING BTREE (`IPLOCID`),
KEY `Index_3` USING BTREE (`IPADDR_FROM`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;
CREATE TABLE `cdIPLocation` (
`IPLOCID` int(10) unsigned NOT NULL default '0',
`Country` varchar(4) default NULL,
`Region` int(10) unsigned default NULL,
`City` varchar(90) default NULL,
`PostalCode` varchar(10) default NULL,
`Latitude` float NOT NULL,
`Longitude` float NOT NULL,
`MetroCode` varchar(4) default NULL,
`AreaCode` varchar(4) default NULL,
`State` varchar(45) default NULL,
`Continent` varchar(10) default NULL,
PRIMARY KEY (`IPLOCID`)
) ENGINE=MyISAM AUTO_INCREMENT=218611 DEFAULT CHARSET=latin1;
and
CREATE TABLE 'data'{
'IP' varchar(50)
'SCORE' int
}
My task is to join these three tables and find the location data for given IP address.
My query is as follows:
select
t.ip,
l.Country,
l.State,
l.City,
l.PostalCode,
l.Latitude,
l.Longitude,
t.score
from
(select
ip, inet_aton(ip) ipv, score
from
data
order by score desc
limit 5) t
join
cdIPAddressToLocation a ON t.ipv between a.IPADDR_FROM and a.IPADDR_TO
join
cdIPLocation l ON l.IPLOCID = a.IPLOCID
While this query works, it's very very slow, it took about 100 seconds to return the result on my dev box.
I'm using mysql 5.1, the cdIPAddressToLocation has 5.9 million rows and cdIPLocation table has about 0.3 million rows.
When I check the execution plan, I found it's not using any index in the table 'cdIPAddressToLocation', so for each row in the 'data' table it would do a full table scan against table 'cdIPAddressToLocation'.
It is very weird to me. I mean since there are already two indexes in table 'cdIPAddressToLocation' on columns 'IPADDR_FROM' and 'IPADDR_TO', the execution plan should exploit the index to improve the performance, but why it didn't use them.
Or was there something wrong with my query?
Please help, thanks a lot.
Have you tried using a composite index on the columns cdIPAddressToLocation.IPADDR_FROM and cdIPAddressToLocation.IPADDR_TO?
Multiple-Column Indexes