以下是我昨天在c#中使用SqlClient获取排序结果集时遇到的奇怪情况。
以SQL查询为例:
SELECT Num, Name FROM Customer WHERE Num LIKE '%V%' OR Name LIKE '%V%' ORDER BY Num ASC
在这种特殊情况下,要排序的结果集大约有100行。
问题是:如果我在sql服务器本身上运行查询,它会非常快!结果几乎在我点击"Run query“的那一刻就显示出来了。但是当我使用SqlClient在C#中运行查询时,它的速度非常慢(大约5-10秒)。我对程序的每一个小部分进行了基准测试,
我从一个框架中准备了一条语句,如下所示:
SELECT OH.ORDER_ID, MAX(OS.STATUS_DATETIME) FROM public.ORDER_HEADER OH, public.ORDER_STATUS OS WHERE ((OH.ORDER_ID = OS.ORDER_ID AND OH.STATUS_ID = ? AND OS.STATUS_ID = ?)) GROUP BY OH.ORDER_
ID HAVING (MAX(OS.STATUS_DATETIME) <= ?) ORDER BY OH.ORDER_ID ASC
OrderHeader有30万行,
我有一个在15秒内返回超过100000行的视图。该视图返回一个字段ElementId。我有一个具有主键Id的表元素。
SELECT MV.ElementId
FROM MyView MV
当我在视图和表之间应用连接时,我的查询非常慢(> 4分钟),如下所示:
SELECT E.Id
FROM MyView MV
INNER JOIN Elements E ON E.Id = MV.ElementId
WHERE E.CustomerId = @CustomlerId
为什么两个查询的执行时间会有这么大的差异?如何优化第二个查询?
我使用SQL Server 2014
我有一个仪表板,显示使用5个单独的SELECT count (*)查询计算的5个实时总数。将这些结果插入到页面中,并使用
Using rdr As SqlDataReader = db.ExecDataReader(qry1)
rdr.Read()
qa1.InnerText = rdr(rdr.GetName(0))
End Using
Using rdr As SqlDataReader = db.ExecDataReader(qry2)
rdr.Read()
我尝试执行一个sql查询(如下所示),运行时间为10秒,由于是在生产环境中,所以我停止了它,以确保没有进行sql锁定。
SELECT TOP 1000000 *
FROM Table T
Where CONVERT(nvarchar(max), T.Data) like '%SearchPhrase%' --T.Data is initially XML
现在,如果我按创建时间添加一个订单(我不认为这是一个索引),则需要2秒才能完成。
SELECT TOP 1000000 *
FROM Table T
Where CONVERT(nvarchar(max), T
我正试图找到最快的方法来JOIN --一个在PostgreSQL中有一个大表的小表。
请查看下面的最小示例,该示例创建一个包含5.000行的小表和一个3.000.000行的大表:
-- Create small table
CREATE TABLE small_table (
id INTEGER,
text VARCHAR(100)
);
-- Create big table
CREATE TABLE big_table (
id INTEGER
);
-- Insert random data into small table (5.000 rows)
INSERT
我试图构建一个带有查询的报表,通过FDW访问不同的postgres。
我猜它为什么会这样运作。没有where子句的第一个查询是可以的:
SELECT s.student_id, p.surname
FROM rep_student s inner JOIN rep_person p ON p.id = s.person_id
但是,在哪里添加caluse会使查询速度慢100倍(40对0.1s):
SELECT s.student_id, p.surname
FROM rep_student s inner JOIN rep_person p ON p.id = s.person_id
WH
我所做的是在网站上
我在R下使用了RPostgreSQL包,因为我想同时操作其他文件。正如你从上面的网站上看到的,这个表格非常大。使用RPostgreSQL完成选择需要两个多小时。但现在,我在psql下使用相同的SQL代码,而不是使用RpostgreSQL。这只花了几分钟。为什么?
R的代码是:
sql='SELECT * into new_table FROM table_1 WHERE EXISTS (SELECT 1 FROM table_2 WHERE column=table_1.column_1) AND EXISTS (SELECT 1 FROM table_2 WHER
得到了一个运行非常快的脚本(大约20秒来处理30,000条记录),而我正在处理100,000条左右的记录。脚本从postgresql数据库抓取记录,对它们进行处理,然后在数据库中标记这些记录已被处理。
问题是,我现在已经把脚本指向了一个有5000万条记录的数据库,现在10,000条记录大约需要160秒!那太慢了。
我能做些什么来加速我的更新吗?
我的python和SQLAlchemy核心代码是:
def process_records(no_of_records, data)
for x in range(no_of_records):
my_data = data[x
我正在使用MySql,并且遇到一个给定的查询从一个事务表中计算收入的情况。选择的事务可以跨越1天、1周或1个月。
SELECT
revenue formula
FROM
product inner join
account on key_condition1 inner join
transaction on key_condition2
WHERE
tx.ENTRYDATE >= '2013-06-17 00:00:00' AND tx.ENTRYDATE < '2013-07-24 00:00:00'
GROU
我在我的web服务器上运行下面的MySQL查询,数据库位于一个单独的服务器上:
$sql="select * from call_history where extension_number = '0536*500' and flow = 'in' and DATE(initiated) = '".date("Y-m-d")."' ";
$rs=mysql_query($sql,$pbx01_conn);
echo mysql_num_rows($rs).' Calls IN';
c
我使用的是SQL server 2005,SQL server studio客户端。我有一个很长的存储过程(它做了一堆表连接,一些删除,一些插入和一些更新)周期性地运行(大约每隔2分钟)。
使用此sp后,我注意到数据库有时没有响应(在SP未运行时会发生几次,在SP运行期间会发生很多次)。当数据库没有响应时,我不能从SQL server studio客户端打开新的连接,如果我运行一个查询/sp,状态将变为running,并且永远保持这种状态,直到我从控制面板admin-tools手动重置SQL服务。
你见过类似的问题吗?
可能是因为我新创建的SP做了太多的事情而导致数据库崩溃?
需要一些建议..。
我已经看到了很多关于执行AJAX实时搜索的不同方法的讨论,其中使用了自动完成函数来建议搜索术语。就像在谷歌或者YouTube上。
一些教程建议使用AJAX从XML文件中获取结果。有人建议直接查询数据库。对于该采取哪种方法,似乎有许多相互矛盾的建议,但对每一种方法的利弊却没有明确的共识。
假设我有一张结构表:
ID TITLE AUTHOR LINK
我想有一个搜索框,自动完成,以提供建议的标题。表是大的- 100000+行。
什么是最好的方法:
在每次击键时直接查询DB (可能会设置一个函数来限制每个用户每秒的#服务器请求)。
查询XML文件。这样更有效
在我的应用程序中,我有两个MySQL表,“单位”和“印象”是一对一的关系。我需要从单元表中获取所有广告单元的列表,但也获取每个广告单元的印象计数。
我有两个SELECT查询来完成这项任务(在本例中简化了),首先使用子select:
SELECT
(SELECT COUNT(*) FROM impressions WHERE impression_unit_id = unit_id) AS impressions_count,
unit_id
FROM units;
然后使用GROUP BY:
SELECT
COUNT(impression_id) AS impress
当运行一个连接3个大表中的数据的查询时,我得到一个错误:
The SELECT would examine more than MAX_JOIN_SIZE rows; check your WHERE and use SET SQL_BIG_SELECTS=1 or SET SQL_MAX_JOIN_SIZE=# if the SELECT is okay