데이터 베이스 MySQL 튜토리얼 Access和Firebird的性能比较

Access和Firebird的性能比较

Jun 07, 2016 pm 03:50 PM
access 성능 비교하다

虽然Firebird总体上是比Access好,但是没有传说的那么好,至少在Net环境下。 1、测试环境 A、系统环境 操作系统:Windows XP Professional Server Pack 2 CPU:Intel(R) Pentium(R) 4 CPU 3.00GHZ 2.99GHZ 内存:1G B、代码环境 NET2.0、Access2003、Firebir

虽然Firebird总体上是比Access好,但是没有传说的那么好,至少在Net环境下。

1、测试环境

  A、系统环境

  操作系统:Windows XP Professional Server Pack 2

  CPU:Intel(R) Pentium(R) 4 CPU 3.00GHZ 2.99GHZ

  内存:1G

  B、代码环境

  NET2.0、Access2003、Firebird2.1、

  Firebird的NET2.0访问API(FirebirdSql.Data.FirebirdClient.dll)

2、数据库

EmployeeInfo表:

CREATE TABLE EMPLOYEEINFO(<br>EID Integer NOT NULL,<br>ENAME Varchar(50),<br>ETELEPHONE Varchar(50),<br>EMOBILE Varchar(50),<br>EADDRESS Varchar(200),<br>EWORK Varchar(50),<br>ECOMPANY Varchar(50),<br>EAGE Integer,<br>ESCHOOL Varchar(50),<br>EBIRTHDAY Date,<br>EFAVOURATE Varchar(500),<br>ISMVP Integer,<br>ELEVEL Integer,<br>ENABLE_FLAG Integer,<br>CONSTRAINT EMPLOYEEINFO_NAME PRIMARY KEY (EID)<br>);

3、测试代码

  见附带文件

4、性能比较

  下面的数字是以毫秒为单位的,对于两个数据库连接的性能在4.1中有记录,因为其他的操作连接的性能基本相同,所以在其他的比较中省略了。

  新增操作:需要从数据表中获取ID,所以都需要执行ExecuteScalar

  Access:SELECT max(EId) + 1 FROM EmployeeInfo

  Firebird:SELECT first 1 GEN_ID( EMPLOYEEINFO_KEY_GEN, 1) FROM RDB$GENERATORS

  预编优化:这种方式是采用IDbCommand的Prepare方法来进行的。

 

  4.1、单条数据的操作比较

 

  1、新增操作

  IDbConnection.Open() IDbCommand.ExecuteScalar() IDbCommand.ExecuteNonQuery()
Access 174.238416 102.448561 41.695030
  159.298931 101.921224 41.537487
  185.202748 102.383310 36.008230
       
FireBird 381.801163 59.864800 38.652679
  360.196079 69.475482 39.371224
  343.838800 60.606686

39.241575

  2、  修改操作

  Access FireBird
IDbCommand.ExecuteNonQuery() 125.531627 88.544622
  105.508891 88.177334
  145.817176 107.016208
4.2、100条数据的操作比较

  1、新增操作

  IDbCommand.ExecuteScalar() IDbCommand.ExecuteNonQuery()
Access 275.494317 234.020361
  261.396954 237.707107
  252.611140 253.758009
     
预编译优化 124.001096 100.539268
  124.581257 98.269848
  125.422189 99.034516
     
预编译+事务控制 156.688199 99.945657
  116.741034 80.133735
  113.269134 82.601144
     
FireBird 838.318433 969.816292
  887.597984 1064.949756
  818.385955 1022.706634
     
预编译优化 308.331690 437.868342
  283.292181 551.306577
  222.096816 455.877916
     
预编译+事务控制 70.281354 109.981409
  72.199458 96.185741
  69.851572 91.551454

  2、  修改操作

  Access FireBird
IDbCommand.ExecuteNonQuery() 411.009308 913.508742
  396.797053 868.117194
  399.259210 912.881623
     
预编译优化 177.652866 692.759320
  163.982479 709.243510
  171.324164 644.216015
     
预编译+事务控制 158.654429 106.195976
  154.795059 101.715139
  157.486357 104.424021
4.3、1000条数据的操作比较

  1、新增操作

  IDbCommand.ExecuteScalar() IDbCommand.ExecuteNonQuery()
Access 1651.840012 2133.541653
  1663.862358 2144.262530
  1631.403159 2135.223692
     
预编译优化 796.962979 808.875114
  785.243696 793.758126
  809.209726 797.399235
     
预编译+事务控制 728.416438 610.310033
  873.088523 898.503055
  673.583191 603.249033
     
FireBird 7737.366552 9359.178169
  7308.689064 10904.423101
  7724.148976 11846.604215
     
预编译优化 3716.587264 5723.248900
  3234.737922 5430.311542
  2686.714810 4821.239747
     
预编译+事务控制 522.050014 642.658276
  522.211388 665.879242
  532.323116 658.373523

  2、  修改操作

  Access FireBird
IDbCommand.ExecuteNonQuery() 3290.740559 7873.507740
  3991.333695 7822.996734
  3293.068174 7116.759956
     
预编译优化 1398.160890 6482.893171
  1254.979979 6302.055985
  1245.802121 6272.648019
     
预编译+事务控制 1097.316477 648.313099
  1221.636742 648.390276
  1104.532568 648.983446
4.4、10000条数据的操作比较

  1、新增操作

  IDbCommand.ExecuteScalar() IDbCommand.ExecuteNonQuery()
Access 15321.344697 20695.870283
  15522.056899 20775.041631
  15319.349251 20727.514825
     
预编译优化 10627.689828 9980.130051
  11161.361432 10432.259290
  10580.619317 9925.817398
     
预编译+事务控制 6191.647891 6037.020082
  6855.991305 6306.552880
  6659.638395 6042.067384
     
FireBird 92770.835360 119561.011190
  115369.304783 143528.391259
  135761.012112 165465.676440
     
预编译优化 61204.197587 94345.156610
  36930.112494 57278.146122
  40012.081468 66210.081814
     
预编译+事务控制 5407.627206 6910.738469
  5488.005238 7106.846560
  5524.538831 6740.408060

  2、  修改操作

  Access FireBird
IDbCommand.ExecuteNonQuery() 39694.855804 99310.751707
  35354.716525 90011.911178
  36534.236655 91112.061482
     
预编译+事务控制 10469.019093 7230.535415
  10444.395741 7682.581104
  10329.116616 7390.059610
4.5、100000条数据的操作比较

  1、新增操作

 

  IDbCommand.ExecuteScalar()

IDbCommand.ExecuteNonQuery()
Access

  198287.389450

223781.708768
 

  207229.904897

227152.302183
 

  236267.203150

251924.067059
     
预编译优化

  75745.455466

80136.166440
 

  80215.392531

84041.511179
 

  83531.057454

85371.502942
     
预编译+事务控制

  73753.320106

62696.035496
 

  70442.642879

69222.947557
 

  79447.569370

70056.168140
     
FireBird

  >30分钟

 
 
预编译优化 297619.975597

  551716.871984

     
预编译+事务控制 50412.421478

  62230.369322

  52912.052985

  69931.034354

  52509.019944

  66763.649792

       

  2、  修改操作

  Access FireBird
IDbCommand.ExecuteNonQuery() 332451.315712

  1260805.499906

  347068.025903
预编译优化 164528.339360 643502.447928
预编译+事务控制 108129.478762 81140.664313
4.6、500000条数据的操作比较

  1、新增操作

  IDbCommand.ExecuteScalar()

  IDbCommand.ExecuteNonQuery()

预编译优化Access 479207.809593

  465971.617839

  377229.922041

  367370.094465

预编译+事务控制 336857.065763

  316500.809166

     
预编译优化FireBird

  >60分钟

预编译+事务控制

  273555.344525

361675.703063
       

  2、  修改操作

  Access FireBird
预编译+事务控制 512516.135296 473002.155994
4.7、100条数据的查询比较
  Access FireBird
SELECT * FROM table 561.603041 705.621894
  528.617866 804.226516
SELECT * From table WHERE name like ‘%...%’ 531.510943 720.582087
  525.499398 761.811122
4.8、1000条数据的查询比较
  Access FireBird
SELECT * FROM table 588.116789 771.333159
  615.835833 743.432148
SELECT * From table WHERE name like ‘%...%’ 557.460599 715.724471
  564.812336 724.736215
4.9、10000条数据的查询比较
  Access FireBird
SELECT * FROM table 1134.614770 1337.971064
  1015.374508 1261.249305
SELECT * From table WHERE name like ‘%...%’ 737.451880 925.413277
  751.952307 910.842727
4.10、100000条数据的查询比较
  Access FireBird
SELECT * FROM table 6501.658483 6335.985464
  5426.486788 6899.610531
SELECT * From table WHERE name like ‘%...%’ 3204.588434 3298.303960
  3203.261492 3810.441583
4.11、500000条数据的查询比较
  Access FireBird
SELECT * FROM table 28380.649119 34032.733181
  28227.096199 34557.834127
SELECT * From table WHERE name like ‘%...%’ 18065.770127 19266.049635
  18412.904426 17163.350933
4.12、数据库文件增长量的比较

  Access文件大小的增长是非常恐怖的,1000000条左右的数据基本上可以达到Access的极限(2G)

  Firebird文件大小的增长和Access比较起来,比Access要小很多,基本上是差了几个级别

  下面是分别进行大数量操作后的文件情况:

  Firebird 94808KB

  Access  1123424KB

  在不压缩数据库的前提下,Access增加100W左右的数据达到2G,Firebrid增加1000W左右的数据达到2G。

 

5、测试总结

  根据上面的性能比较,可以得出以上几点结论:

  1. 对于大批量的数据操作,一定要采用预编译或批量提交的方式进行操作,如果是在Firebird中,一定加事务进行处理,因为在Firebird中,有事务的性能可以提升6-10倍左右。在Access中,虽然性能提升不多,但是还是最好都加上事务控制。这一方面增加操作的原子性,并且也减少数据库的读写次数。
  2. Access一般支持2G左右的数据,当数据量超过这个限制后,Access不能写入数据。所以当数据量在2G下的时候才选用。Firebird对于数据的支持大于/等于16G,而且在优化后的整体性能要强于Access。
  3. Access在没有压缩的前提下,如果大批量的进行数据操作(新增/修改),那么数据大小的增长是是Firebird的几倍,一般连续增长100W多的数据就不能再插入数据了。而Firebird 在这点上是很好的,同时也没有限制。
본 웹사이트의 성명
본 글의 내용은 네티즌들의 자발적인 기여로 작성되었으며, 저작권은 원저작자에게 있습니다. 본 사이트는 이에 상응하는 법적 책임을 지지 않습니다. 표절이나 침해가 의심되는 콘텐츠를 발견한 경우 admin@php.cn으로 문의하세요.

핫 AI 도구

Undresser.AI Undress

Undresser.AI Undress

사실적인 누드 사진을 만들기 위한 AI 기반 앱

AI Clothes Remover

AI Clothes Remover

사진에서 옷을 제거하는 온라인 AI 도구입니다.

Undress AI Tool

Undress AI Tool

무료로 이미지를 벗다

Clothoff.io

Clothoff.io

AI 옷 제거제

AI Hentai Generator

AI Hentai Generator

AI Hentai를 무료로 생성하십시오.

인기 기사

R.E.P.O. 에너지 결정과 그들이하는 일 (노란색 크리스탈)
3 몇 주 전 By 尊渡假赌尊渡假赌尊渡假赌
R.E.P.O. 최고의 그래픽 설정
3 몇 주 전 By 尊渡假赌尊渡假赌尊渡假赌
R.E.P.O. 아무도들을 수없는 경우 오디오를 수정하는 방법
3 몇 주 전 By 尊渡假赌尊渡假赌尊渡假赌

뜨거운 도구

메모장++7.3.1

메모장++7.3.1

사용하기 쉬운 무료 코드 편집기

SublimeText3 중국어 버전

SublimeText3 중국어 버전

중국어 버전, 사용하기 매우 쉽습니다.

스튜디오 13.0.1 보내기

스튜디오 13.0.1 보내기

강력한 PHP 통합 개발 환경

드림위버 CS6

드림위버 CS6

시각적 웹 개발 도구

SublimeText3 Mac 버전

SublimeText3 Mac 버전

신 수준의 코드 편집 소프트웨어(SublimeText3)

Windows 11에서 백그라운드 애플리케이션을 비활성화하는 방법_Windows 11 튜토리얼에서 백그라운드 애플리케이션을 비활성화하는 방법 Windows 11에서 백그라운드 애플리케이션을 비활성화하는 방법_Windows 11 튜토리얼에서 백그라운드 애플리케이션을 비활성화하는 방법 May 07, 2024 pm 04:20 PM

1. Windows 11에서 설정을 엽니다. Win+I 단축키나 다른 방법을 사용할 수 있습니다. 2. 앱 섹션으로 이동하여 앱 및 기능을 클릭합니다. 3. 백그라운드에서 실행되는 것을 방지하려는 애플리케이션을 찾으세요. 점 3개 버튼을 클릭하고 고급 옵션을 선택합니다. 4. [백그라운드 애플리케이션 권한] 섹션을 찾아 원하는 값을 선택하세요. 기본적으로 Windows 11은 전원 최적화 모드를 설정합니다. 이를 통해 Windows는 애플리케이션이 백그라운드에서 작동하는 방식을 관리할 수 있습니다. 예를 들어, 배터리를 절약하기 위해 배터리 절약 모드를 활성화하면 시스템은 모든 앱을 자동으로 닫습니다. 5. 애플리케이션이 백그라운드에서 실행되는 것을 방지하려면 [안함]을 선택합니다. 프로그램이 알림을 보내지 않거나 데이터를 업데이트하지 못하는 경우 등을 확인할 수 있습니다.

DeepSeek PDF를 변환하는 방법 DeepSeek PDF를 변환하는 방법 Feb 19, 2025 pm 05:24 PM

DeepSeek은 파일을 PDF로 직접 변환 할 수 없습니다. 파일 유형에 따라 공통 문서 (Word, Excel, PowerPoint) : Microsoft Office, LibreOffice 및 기타 소프트웨어를 사용하여 PDF로 내보내십시오. 이미지 : 이미지 뷰어 또는 이미지 처리 소프트웨어를 사용하여 PDF로 저장하십시오. 웹 페이지 : 브라우저의 "PDF로 인쇄"기능 또는 전용 웹 페이지에서 PDF 도구를 사용하십시오. 드문 형식 : 오른쪽 변환기를 찾아 PDF로 변환하십시오. 올바른 도구를 선택하고 실제 상황에 따라 계획을 개발하는 것이 중요합니다.

다양한 Java 프레임워크의 성능 비교 다양한 Java 프레임워크의 성능 비교 Jun 05, 2024 pm 07:14 PM

다양한 Java 프레임워크의 성능 비교: REST API 요청 처리: Vert.x가 최고이며 요청 속도는 SpringBoot의 2배, Dropwizard의 3배입니다. 데이터베이스 쿼리: SpringBoot의 HibernateORM은 Vert.x 및 Dropwizard의 ORM보다 우수합니다. 캐싱 작업: Vert.x의 Hazelcast 클라이언트는 SpringBoot 및 Dropwizard의 캐싱 메커니즘보다 우수합니다. 적합한 프레임워크: 애플리케이션 요구 사항에 따라 선택하세요. Vert.x는 고성능 웹 서비스에 적합하고, SpringBoot는 데이터 집약적 애플리케이션에 적합하며, Dropwizard는 마이크로서비스 아키텍처에 적합합니다.

오라클에서 dbf 파일을 읽는 방법 오라클에서 dbf 파일을 읽는 방법 May 10, 2024 am 01:27 AM

Oracle은 다음 단계를 통해 dbf 파일을 읽을 수 있습니다. 외부 테이블을 만들고 dbf 파일을 참조하여 데이터를 Oracle 테이블로 가져옵니다.

C++에서 멀티스레드 프로그램의 성능을 최적화하는 방법은 무엇입니까? C++에서 멀티스레드 프로그램의 성능을 최적화하는 방법은 무엇입니까? Jun 05, 2024 pm 02:04 PM

C++ 다중 스레드 성능을 최적화하기 위한 효과적인 기술에는 리소스 경합을 피하기 위해 스레드 수를 제한하는 것이 포함됩니다. 경합을 줄이려면 가벼운 뮤텍스 잠금을 사용하세요. 잠금 범위를 최적화하고 대기 시간을 최소화합니다. 동시성을 향상하려면 잠금 없는 데이터 구조를 사용하세요. 바쁜 대기를 피하고 이벤트를 통해 스레드에 리소스 가용성을 알립니다.

Botanix 해석: 네트워크 자산 관리를 위한 분산형 BTC L2(대화형 튜토리얼 포함) Botanix 해석: 네트워크 자산 관리를 위한 분산형 BTC L2(대화형 튜토리얼 포함) May 08, 2024 pm 06:40 PM

어제 BotanixLabs는 Polychain Capital, Placeholder Capital 등의 참여로 총 1,150만 달러의 자금 조달을 완료했다고 발표했습니다. 자금 조달은 BTCL2Botanix와 동등한 분산형 EVM을 구축하는 데 사용됩니다. Spiderchain은 EVM의 사용 편의성과 비트코인의 보안을 결합합니다. 2023년 11월 테스트넷이 시작된 이후 활성 주소는 200,000개가 넘었습니다. Odaily는 이번 기사에서 Botanix의 특징적인 메커니즘과 테스트넷 상호 작용 프로세스를 분석할 것입니다. Botanix 공식 정의에 따르면 Botanix는 비트코인을 기반으로 구축된 분산형 Turing-complete L2EVM이며 두 가지 핵심 구성 요소로 구성됩니다. Ethereum Virtual Machine

C++와 다른 언어의 성능 비교 C++와 다른 언어의 성능 비교 Jun 01, 2024 pm 10:04 PM

고성능 애플리케이션을 개발할 때 C++는 특히 마이크로 벤치마크에서 다른 언어보다 성능이 뛰어납니다. 매크로 벤치마크에서는 Java, C# 등 다른 언어의 편의성과 최적화 메커니즘이 더 나은 성능을 발휘할 수 있습니다. 실제 사례에서 C++는 이미지 처리, 수치 계산 및 게임 개발에서 우수한 성능을 발휘하며 메모리 관리 및 하드웨어 액세스에 대한 직접적인 제어는 확실한 성능 이점을 제공합니다.

Java 프레임워크의 성능 비교 Java 프레임워크의 성능 비교 Jun 04, 2024 pm 03:56 PM

벤치마크에 따르면 소규모 고성능 애플리케이션의 경우 Quarkus(빠른 시작, 낮은 메모리) 또는 Micronaut(TechEmpower 우수)가 이상적인 선택입니다. SpringBoot는 대규모 풀 스택 애플리케이션에 적합하지만 시작 시간과 메모리 사용량이 약간 느립니다.

See all articles